Login
Login-Name Passwort


 
Newsletter
Werbung

Mi, 23. Juli 2014, 09:26

Software::Entwicklung

Firefox erhält JavaScript-String-Optimierung

Eine Optimierung, die in Firefox 33 zu erwarten ist, wird für JavaScript-Strings wesentlich weniger Speicher benötigen. Damit wird in Firefox 33 auch der Gesamt-Speicherbedarf etwas sinken und die Geschwindigkeit steigen.

mozilla.org

Mozilla-Entwickler Jan de Mooij hat im Mozilla JavaScript-Blog die Früchte seiner Arbeit der letzten zwei Monate vorgestellt. Er arbeitete daran, die String-Speicherung in der JavaScript-Engine SpiderMonkey zu verbessern. Verblüffenderweise stellte sich heraus, dass der größte Teil der Strings in Latin1-Kodierung speicherbar ist, was den Speicherbedarf gegenüber der bisher verwendeten UTF16-Kodierung halbiert. Für die Benutzer von Firefox und für JavaScript-Code ergibt sich keine Änderung, da die Optimierung vollständig intern ist.

Seit Brendan Eich die erste Version von SpiderMonkey im Jahr 1995 schrieb, speicherte die JavaScript-Engine Strings in der UTF16-Kodierung, die in der Mozilla-Variante genau zwei Bytes pro Zeichen belegt. Im Laufe der Zeit kamen weitere String-Typen hinzu, darunter kurze Strings, die ihre Zeichen im String-Objekt selbst speichern und keine zusätzliche Speicherallokation benötigen (Inline-Strings) und Ropes. Das sparte Speicher und verbesserte die Geschwindigkeit, die Kodierung wurde jedoch nie geändert.

Speicherbedarf von Firefox vor und nach der String-Optimierung

Jan de Mooij

Speicherbedarf von Firefox vor und nach der String-Optimierung

Jan de Mooij begann vor zwei Monaten, den String-Datentyp zu ändern, so dass er auch Latin1-kodierte Strings speichern kann. Nachdem dies implementiert und alle Code-Stellen, die auf die interne String-Darstellung zugreifen, angepasst waren, kann de Mooij jetzt beeindruckende Zahlen vorlegen. Um diese Zahlen verständlich zu machen, muss man wissen, wie die Strings intern gespeichert werden.

Die interne String-Klasse von SpiderMonkey besaß vor der Änderung ein Feld, in dem die Länge (28 Bit) und vier Flags (4 Bit) kombiniert gespeichert wurden. Da die Flags nicht mehr ausreichten, machte de Mooij daraus zwei 32-Bit-Felder. Ein neues Flag zeigt nun an, wenn ein String in Latin1-Kodierung vorliegt. Ist ein String kurz, kann er direkt in der Datenstruktur gespeichert werden. Ist er länger, muss zusätzlicher Speicher auf dem Heap allokiert werden, was Zeit kostet, und ein Zeiger darauf wird in der String-Struktur gespeichert.

Wie die Grafik zeigt, wurde der Speicherbedarf für die String-Strukturen geringfügig kleiner, was wohl daran liegt, dass es viele kurze Strings gibt. Bei den langen Strings, die auf dem Heap allokiert werden, sank der Speicherbedarf dagegen um mehr als 50%, wovon maximal 50% auf die Halbierung der Zeichenlänge gehen und der Rest dadurch zustande kommt, dass einige Strings nun kurz genug sind, um sie direkt in der Struktur zu speichern. Vor der Änderung waren etwa 65% aller Strings Inline-Strings, jetzt sind es 87%.

Bei nicht-westlichen Sprachen, die nicht mit dem Latin1-Zeichensatz auskommen, ist die Einsparung erwartungsgemäß nicht ganz so groß, aber dennoch spürbar. Etwa 72% aller Strings sind immer noch als Latin1 kodierbar, da sie interne Strings, DOM-Bezeichner und ähnliches sind.

Die Speicher-Ersparnis und die Abtrennung der Flags vom Längenfeld führte auch zu höher Geschwindigkeit. In vielen JavaScript-Benchmarks stieg das Ergebnis um 11% oder mehr, in einem Fall um 36%. Unter Android waren die Verbesserungen noch etwas größer.

Naheliegend wäre es gewesen, UTF-16 durch das universelle UTF-8 zu ersetzen. Das hätte jedoch laut de Mooij einige Nachteile gehabt, jedenfalls zum jetzigen Zeitpunkt. Die aktuellen Änderungen können jedoch dazu führen, dass die Umstellung auf UTF-8 leichter wird, wenn sie je kommen sollte. Fürs erste wäre es zuviel Arbeit gewesen, da die HTML-Engine Gecko fast überall UTF-16 verwendet. Auch die Umstellung von SpiderMonkey wäre viel mehr Arbeit gewesen. Zudem ist der Zugriff auf einzelne Zeichen in UTF-8 langsamer als in Latin1, was sich auf die Geschwindigkeit nachteilig hätte auswirken können.

Die String-Optimierung ist jetzt in Firefox Nightly verfügbar und wird diese Woche noch in Firefox Aurora erscheinen. Sie wird die Endanwender in Firefox 33 erreichen, der in drei Monaten erscheinen soll, und damit auch in Firefox OS 2.1.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung