Hakuna matata!

Vielleicht kann dir jemand, der mehr oder tiefergehend Ahnung von JavaScript hat (1UnitedPower vielleicht?) da noch eine fundiertere Erklärung oder Begründung geben. Was ich geschrieben hatte entspringt halt meinem Laienwissen und persönlicher Erfahrung.

Also JavaScript und Performance. Es gibt zich Arten, um selbst die letzte nano Sekunde aus einer for-Schleife herauszukitzeln. Es gibt Leute, die befassen sich sehr ausführlich mit der Theorie dahinter, also was die JavaScript-Engine machen muss, um diese oder jene for-Schleifen-Variation auszuführen. Die Resultate aus der Theorie werden dann mit Benchmarktests gemessen und untereinander verglichen. Das ist sehr wichtige Arbeit, keine Frage.

Aber, es ist ein Fehler hinzugehen, nachdem man so einen Test gelesen hat, und nur noch die hochoptimierte for-Schleife zu benutzen. Denn die Millisekundenbruchteile, die man dadurch sparen kann, sind verschwindend gering, wenn man sie gegen die Zeit aufwiegt, die bei komplexen DOM-Manipulationen verloren geht. Und nur um das sicherzustellen, die for-Schlefe und die DOM-Manipulationen haben hier nur exemplarischen Charakter.

In den allerwenigsten Fällen, wird man überhaupt Probleme mit der Performanz kriegen, und wenn doch, dann ist es wenig hilfreich auf Verdacht hier und da ein paar for-Schleifen zu optimieren oder ein paar Eventlistener zu lösen. In solchen Fällen, sollte man sich bemühen erstmal rauszufinden, welcher Übeltäter das Programm so langsam werden lässt, also wo der Flaschenhals versteckt ist. Dann sollte man sich gezielt überlegen, was man dagegen tun kann, und dabei hilft einem dann wieder die Theorie.

Meine Divise ist deshalb von vornerein und immer, wenn es möglich ist, gut leserlichen und ausdrucksstarken Quelltext zu schreiben und da sind Performanz-Tweaks meistens nun mal kontraproduktiv.

Und wenn es dann doch mal ans Eingemachte geht, dann ist der Griff zum CPU-Profiler bzw. zum Memory-Profiler der erste Schritt, den man unternehmen sollte.