🚀 go-pugleaf

Hi,

vorne weg: Ich habe einfach mal 'strcmp()' und 'bool operator==(string
const &, string const &)' verglichen (Code und genaue Ergebnisse kann
ich auch posten, ist aber nicht so furchtbar interessant; die
relevanten Ergebnisse erwaehne ich hier ungefaehr). Ich kann nicht
argumentieren, dass 'operator==()' schneller waere: das ist nicht der
Fall, auch dann nicht, wenn ich den Vergleich "fair" mache (der
Vergleich der vorgeschlagen wurde ist naemlich, IMHO, nicht fair). Es
bleibt beim gcc-2.7.2 mit '-O2' ein Faktor von ungefaehr zwei, den ich,
bei geeigneter Wahl der Strings, langsamer bin. Bei dem vorgeschlagenen
Vergleich gibt es da schon einen deutlich groesseren Faktor in der
Groessenordnung von ~30.

Ullrich von Bassewitz (uz@wuschel.ibb.schwaben.com) wrote:
: Da class string den String prinzipiell immer auf den Heap packt ist wohl
: klar, woher der Performance Unterschied kommt. Stell Dir folgende Funktion
: vor:

:         int StrCmp1 (const string& lhs, const string& rhs);
:         // Compare two strings
: und     
:         int StrCmp2 (const char* lhs, const char* rhs);
:         // Compare two string

: Wenn Du einen Aufuf hast, wie:

:         if (StrCmpX ("foo", "bar") == 0) { /* ... */ }

So einen Aufruf habe ich aber garnicht! Da kommen ja 'char const*' vor
:-) Ich habe aber immer nur 'string's. Mit anderen Worten: Der Vergleich
ist meiner Meinung nach nicht fair. Wenn dann ist ein Aufruf
wie

	  string s1("foo");
	  string s2("bar");
	  // hier beginnt die Zeitmessung

	  if (StrCmpX(s1, s2) == 0) { }

angesagt. Sicher muss ich meine 'string's irgendwann konstruieren, aber
entweder ist der Aufwand zu vernachlaessigen (fuer die Literale: bevor
sich was bei der Zeitmessung tut, muss ich schon fleissig viele
'string's anlegen...) oder sie muessen auch als 'char*' angelegt
werden, was ungefaehr den selben Aufwand hat.

: dann werden das eine mal einfach zwei Zeiger uebergeben, das andere Mal
: werden zwei Objekte konstruiert (dazu wird Speicher auf dem Heap belegt und
: der String dort rein kopiert), nach dem Aufruf wird der belegte Speicher
: wieder freigegeben.

Ja, sicher. Wie gesagt, das ist, IMHO, kein vernuenftiger Vergleich.
Aber, und das habe ich auch schon gesagt: Auch wenn man die 'string's
vorher anlegt, bleibt es langsamer. Naja, bei langen Strings ist
'string' schneller (lang == > 50)

: Ich habe nicht gesagt, dass die niedrigere Performance tatsaechlich eine
: Rolle spielt, das tut sie in den meisten Faellen nicht (auch wenn 99% aller
: Programmierer fest davon ueberzeugt sind, dass genau ihr Programm mit -O9
: uebersetzt werden muss, und dass Bounds Checking bei Arrays des Teufels ist,
: weil es zwar Bugs abfaengt, aber die Performance drueckt).

Zu dem Thema habe ich sowieso schon immer eine andere Meinung: mein
Code ist zwar schon teilweise optimiert (wo es noetig war oder wo ich
Zeit zum Optimieren hatte), aber sonst gehoert er zu den 80% des Code,
der sowieso nicht in den inneren Schleifen liegt. Seit neustem, genauer
seitdem ich intensiv mit Templates arbeite, lohnt sich allerdings auf
jeden Fall -O zu verwenden, da damit offensichtlich eine ganze Menge
'inline' gemacht wird, was die Abstraktion, die ich mit mir
"rumschleppe", billiger (bzw. kostenlos) macht. Ansonsten bin ich eher
auf der Linie von James Kanze (von dem, und vor allem seinem
Programmierstil, halte ich eine ganze Menge...):  Er meint, man soll
alle Tests (z.B. bounds checking) im endgueltigen Code lassen. Der
groesste Teil ist sowieso nicht teuer (80-20 Regel) und den Rest kann
man sich leisten. Der Vorteil: WENN ein Fehler auftritt, dann hat man
wenigstens einen Hinweis, wo der herkam. Im Testing ist er ja
offensichtlich nicht aufgetreten, also ist er schwer zu reproduzieren.
...aber man muss ihn beheben.

: Das Problem ist nicht die Uebergabe, sondern dass strings so implementiert
: sind, dass die Daten auf dem Heap liegen. Das kann in bestimmten
: Konstellationen (wie die oben) zu einer recht lausigen Performance fuehren.

Ja. Allerdings muess eine solche Konstellation auch auftreten koennen.
Wenn man wirklich und fuer alles 'string' verwendet, tut sie das aber
nicht. Es ist schon richtig: halbherzig 'string' zu verwenden ist zu
teuer...

PS: knapp unter 100. Ich muss mich kuerzer fassen...
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic