Performance

Performance gegen gut wartbaren, übersichtlichen Code. Mehrfach habe ich schon geschrieben, dass ich es wichtig finde hier die richtige Balance einzuhalten. Doch wo beginnt die richtige Balance und wo endet Sie, wenn man sich sicher ist einen Quelltext eigentlich nur ein Mal anzufassen, wie beispielsweise beim Setzen einer Konstante?

Letzten Sonntag habe ich euch mein Profiler.js vorgestellt. Heute folgen erste Ergebnisse. Ich habe gespielt mit Zuweisungen nach Fallunterscheidungen.

Ich muss mich hoch und heilig entschuldigen. Im Oktober habe ich über Flaschenhälse und Schleifenköpfe gebloggt. Sean hatte die Idee, dass Pre-Inkremente schneller seien, als Post-Inkremente.

Um für zukünftige Blogartikel im Bereich Performance Javascripte plattform- und browserübergreifend auf ihre Geschwindigkeit hin testen zu können, habe ich mir hierzu ein Werkzeug gebaut.

Die Entwickler vom Firebug bieten ein kleines Javascript an, das den Nutzen hat, keine Fehler in Browsern, die Firebug nicht installiert haben zu erzeugen, wenn Firebug-Kommandos im Quelltext eingebunden wurden. Ich habe daran 2 marginale Änderungen vorgenommen, sodass der Sourcecode noch ein Quentchen schneller läuft:

In einem netten Gespräch mit einigen anderen Javascriptern haben wir über Memory Leaks in Zusammenhang mit Closures sinniert. IBM hat sich darüber auch Gedanken gemacht und die Ergebnisse mit Erklärungen ins Netz gestellt.

Definitiv lesenswert: Memory leak patterns in JavaScript

John hat in einem Vortrag über die Entwicklung von Javascript-Bibliotheken berichtet, warum es nicht sinnvoll ist, native Datentypen wie String, Array oder Object zu erweitern.

Manchmal sieht man nicht das, was man zu sehen glaubt. Wie viele verschiedene Bilder sind nachfolgend zu sehen?


Vier? fast richtig!

Letzte Woche auf dem Weg zur Arbeit habe ich ein bisschem mit for-Schleifen herumgespielt und eine spannende Entdeckung gemacht. Durch eine kleine Änderung in der Schleifendefinition kann fast die Hälfte der reinen Schleifenlaufzeit gespart werden.

Manchmal passiert es, dass Javascript-Anwendungen langsam werden, beispielsweise weil der Arbeitsspeicher des Clients knapp ist. Als Entwickler steht man jedoch in der Verantwortung, die Anwendung für (möglichst) alle Benutzer nutzbar zu halten. Da bekannt ist, dass viele Browser nicht wirklich so arbeiten, wie man erwartet, sollten wir uns nicht auf die Fähigkeiten des Browsers verlassen, sondern selbst noch ein wenig nachhelfen.