Gute Zeilen, schlechte Zeilen – Folge 3

Folge 3 – Ja oder Nein?

Genau dies ist die häufigste Frage, die man CF stellen sollte, denn mit boolschen
Abfragen kommt es mit Abstand am schnellsten zurecht. Wann immer möglich, sollte
man daher versuchen, IF-Abfragen nur nach true oder false auszuwerten.

Ein paar Beispiele hierzu:

Wenn ein Wert sowieso schon im boolschen Format vorliegt, verschenkt man mit
der linken Variante Zeit, denn in dieser Form wird "true" von CF als String verglichen,
und Stringvergleiche sind de facto langsamer.

Das sind einige Standardkandidaten, die ich in "zu tunenden" Applikationen
immer wieder finde.
Im ersten Fall ist blah eine Zahl, man kann sich das gt
0 also komplett sparen,
da Zahlen > 0 von CF als true angesehen werden.
Der zweite Fall fragt ab, ob blah kein Leerstring ist, aber – wie der Name
schon sagt, es ist eben ein Stringvergleich. len() liefert die Länge des Strings,
also eine Zahl zurück, und diese wird, wie bei Fall 1, als true angesehen,
sofern sie > 0 ist.
Fall 3 zeigt das umgekehrte Beispiel mit not
len(), also wenn 0 als Länge zurückgegeben
wird.
Fall 4 macht sich die Funktionsweise von compareNoCase() zu nutze: bei Gleichheit
zweier Strings wird 0 zurückgegeben, und die ist – jepp, false.

Wirklich, das habe ich *echt so* vorgefunden. Die Stringabfrage nach "yes/no" muss natürlich weg, das zweite fileExists() macht noch weniger Sinn,
denn wenn die erste
Abfrage
false zurückgibt, muss man nicht noch einmal abfragen, ob die Datei nicht vorhanden
ist. 🙂

Wenn man sich sich an diese Art des Abfragens gewöhnt hat, spart man deutlich
an ExecutionTime. Dies alles sind zwar nur kleine Effekte, aber wenn
man nur 10ms Prozessorzeit pro Aufruf spart, spart man bei 5.000 Aufrufen 50s.
Wie sehr sich dies bei HighTraffic-Sites summiert, kann man sich ausrechnen…