Geschwindigkeit string

CSpille schrieb:

ass schrieb:

Lass mal gefährliches Halbwissen, wenn es um den Vergleich String zum Stream geht, ist letzterer wesentlich performanter wenn es um viele Stringverkettungen geht (da ist der std::string nicht die optimale Wahl).

Tut mit leid, dass ich mit meinem gefährlichen Halbwissen genau die
richtige Schlussfolgerung getroffen habe:

Es geht darum, dass die User hier öfters kein Plan haben und irgendein Scheiss daherlabern und die Fragensteller es wirklich glauben. Wenn du dir nicht sicher bist, dann halt deine Finger von der Tastatur oder hol dir eine 2. Meinung bzw. such dir eine verlässliche Quelle aus dem I-Net.

...

...

Hi Zaus,

wie asc bereits angedeutet hat: Erst mit einem profiler messen und dann optimieren. Mit GetTime u.ä. findest Du nur mit Glück die "Zeitfresser". Und bei Vermutungen habe ich in der Vergangenheit zu oft falsch gelegen, als dass ich heute ohne Profilerinformationen eine Aussage treffe.

berniebutt

CSpille schrieb:

Mach dir um sowas keine Sorgen...
Das sind nur Theorie-Idioten die sich davon beeindrucken lassen.

Verwende lieber std::string als mit Arrays C zu proggn.

Bitte keine neue Diskussion C versus C++, da hier oft mit Dogmatismus begleitet!

Für einfache Strings bekannter Länge nimmst du Arrays in C, wenn du damit nicht lange herumfriemelst. Sonst nimmst du vielleicht besser std::string. Die Arrays kommen ohne den Überbau von std::string aus und sind damit theoretisch schneller - und einfach zu handhaben sind sie auch.

Zur Optimierung der Performance gibt es sicher bessere Dinge als gerade Strings! :p Zwei Tage Arbeit oder mehr für herausgekitzelte 100 Millisekunden lohnen nicht!

asc

berniebutt schrieb:

Bitte keine neue Diskussion C versus C++, ...

In einen Punkt doch:

berniebutt schrieb:

...Die Arrays kommen ohne den Überbau von std::string aus und sind damit theoretisch schneller - und einfach zu handhaben sind sie auch.

Gerade das einfach zu handhaben in einem C++ Kontext ist nicht gegeben (Vor allem wenn man sie in Klassen einsetzt, die Kopiert werden - wo dann der automatische Kopierkonstruktor nicht ausreicht etc.). Nicht ohne Grund hat der TR1 die array-Klasse eingeführt die nur ein dünner Wrapper um C-Arrays ist, aber solche Fallstricke berücksichtigt.

Zaus

Alles klar, danke.
An welchen Punkten müsste man denn ansetzen um die Performance zu verbessern? Oder lässt sich das wieder nur mit einem profiler herausfinden? (da wäre ich über einen Tipp über einen guten, kostenlosen einfach zu verwendenden immer noch dankbar)

asc

Zaus schrieb:

An welchen Punkten müsste man denn ansetzen um die Performance zu verbessern? Oder lässt sich das wieder nur mit einem profiler herausfinden?

Prinzipiell kannst du nur mit einem Profiler sicher sein, wo du optimieren musst. Jegliche Zeitmessungen sind ohne Aussagekraft bei der Art von Multitasking die Windows verwendet.

Zaus schrieb:

da wäre ich über einen Tipp über einen guten, kostenlosen einfach zu verwendenden immer noch dankbar

Unter Windows bin ich im kostenlosen Umfeld noch nicht fündig geworden (Entweder Bestandteil von kostenpflichtigen IDE oder als eigenständiges, kostenpflichtiges Produkt).

...

Zaus schrieb:

Hallo
Ich versuche gerade mein Programm was die Geschwindigkeit angeht etwas zu optimieren. Nun habe ich gelesen, dass std::string was die Performance angeht nicht gut sein soll. Kann mir einer was dazu sagen wie das im Vergleich zu char[] aussieht

Hmm... Äpfel und Birnen?

Ein char-Array ist schon etwas ganz anderes als ein std::string-Objekt. Das kann man so allgemein gar nicht vergleichen. Da musst Du schon genau sagen, was Du anstellen willst bzw wie du std::string/char[] benutzen willst. std::string übernimmt die Speicherverwaltung der Zeichenketten. Das ist ein riesen Pluspunkt. Damit werden strings so einfach handhabbar wie ints. Das, was typischerweise am meisten Zeit kostet, ist das Reservieren und Freigeben von Freispeicher. Das passiert aber sowohl bei std::string als auch bei manuell im Freispeicher angelegten char-Arrays. Wenn Du das Gefühl hast, Deine Verwendung von std::string sei langsamer als das manuelle Verwalten von char-Arrays, dann würde ich zunächst mal nachgucken, ob std::string-Objekte bei Dir nicht unnötig kopiert werden.

asc schrieb:

... - versteh mich nicht falsch, sicherlich ist std::string etwas langsamer als sein Low-Level Pendant, aber nicht so wesentlich das dies in der Regel auf Kosten der leichteren Wartbarkeit geändert werden sollte).

Ich würde sogar soweit gehen und sagen, dass spätestens mit der Einführung von move-Semantik in C++0x solche Dinge wie std::string sehr effizient und elegant eingesetzt werden können:

vector<string> quelle()
{
  vector<string> q;
  q.emplace_back("hallo");
  return q;
}

int main()
{
  auto vec = quelle();
}

Hier -- im C++0x-Modus -- wird nirgends etwas kopiert. Das String-Objekt wird direkt im Vector erzeugt. Der Vector wird entweder direkt in vec erzeugt (copy elision) oder nach vec "bewegt" (move construction). Beides sehr billig.

CSpille, wieso löscht du deine Beiträge?

????!!!! schrieb:

CSpille, wieso löscht du deine Beiträge?

http://c-plusplus.net/forum/viewtopic-var-p-is-1927172.html#1927172

Ich würde gerne an dieser Stelle sagen wie arschig das ist...

????!!!! schrieb:

CSpille, wieso löscht du deine Beiträge?

Irgendjemand hat scheinbar einen hilfsbereiten User vergrault.

http://www.c-plusplus.net/forum/viewtopic-var-t-is-270677.html

der typ ist halt geisteskrank

Weil notorische Theoretiker und vermeindlich Fachwissende mal wieder meinen andere Lösungsansätze, oder gar Meinungen nicht aktzeptieren zu müssen. Das gehört hier zum guten Ton und ist vollkommen normal

Ich vermute deswegen will er wohl alles gelöscht haben.

Anonym ist man hier am Besten beraten!

Er möchte wohl nicht weiter Halbwahrheiten verbreiten

volkard

asc schrieb:

Zaus schrieb:

An welchen Punkten müsste man denn ansetzen um die Performance zu verbessern? Oder lässt sich das wieder nur mit einem profiler herausfinden?

Prinzipiell kannst du nur mit einem Profiler sicher sein, wo du optimieren musst. Jegliche Zeitmessungen sind ohne Aussagekraft bei der Art von Multitasking die Windows verwendet.

Das ist einfach falsch. Aber anderen Leuten ein gefährliches Halbwissen attestieren.