@Union: Genau, da spart man so einige Nanosekunden, weil der String nicht mit allen Feldnamen der
Query verglichen werden muss - Buchstabe für Buchstabe. Das ist bei heutigen Rechnerleistungen schon ein erheblicher Performancegewinn. Aber ich erwische mich auch manchmal bei solchen "sinnigen" Optimierungen...
Das einzige, was es heute noch zu optimieren gilt, sind Netzwerkzugriffe, Festplattenzugriffe und vielleicht Bildausgaben. Und vielleicht verschachtelte Schleifen mit Millionen von Durchläufen. 3GHz sind 3 Milliarden Takte pro Sekunde, das Ganze in der Regel auf mehreren Kernen (die anderen Prozesse unterbrechen den Hauptprozess nicht mehr so oft = weniger zeitintensive Prozesswechsel notwendig). Wenn eine komplette Operation 10 Takte dauert, dann sollte man pro Operation dank Pipelining (Jede Operation ist in 10 Einzelschritte zerlegt - während der zweite Schritt der ersten Operation läuft, läuft parallel der erste Schritt der zweiten Operation - durch Abhängigkeiten kann es allerdings sein, dass die nächste notwendige Operation erst feststeht, wenn die vorige abgeschlossen ist, dann beginnt die nächste erst nach dem letzten Schritt/Takt der vorigen Operation) im Schnitt trotzdem nicht mehr als 2 bis 3 Takte rechnen müssen.
Das Vergleichen eines Buchstabens ist übrigens eine Operation. Bei einer durchschnittlichen Feldnamenlänge von 20 Buchstaben und unter der Annahme, dass die Feldnamen immer komplett verglichen werden müssten (was sie nicht müssen) und 20 Feldern pro
Query, sind das im schlimmsten Fall 400 Operationen, nur um den richtigen Pointer zu finden - also ein Bruchteil einer Mikrosekunde. Worst-Case!
"Seit er seinen neuen Computer hat, löst er alle seine Probleme, die er vorher nicht hatte."