Grote boost voor DOM-prestaties - WebKit's innerHTML is 240% sneller

We zijn erg blij om te zien dat een aantal veelvoorkomende DOM-bewerkingen zojuist enorm in snelheid zijn gestegen. De wijzigingen waren op WebKit-niveau en verbeterden de prestaties voor zowel Safari (JavaScriptCore) als Chrome (V8).

Chrome-engineer Kentaro Hara heeft zeven code-optimalisaties in WebKit doorgevoerd. Hieronder vindt u de resultaten, die laten zien hoe veel sneller de JavaScript DOM-toegang is geworden:

Samenvatting van DOM-prestatieverbeteringen

Hieronder geeft Kentaro Hara details over enkele van de patches die hij heeft gemaakt. De links verwijzen naar WebKit-bugs met testcases, zodat u de tests zelf kunt uitproberen. De wijzigingen zijn aangebracht tussen WebKit r109829 en r111133: Chrome 17 bevat ze niet; Chrome 19 wel.

Verbeter de prestaties van div.innerHTML en div.outerHTML met 2,4x (V8, JavaScriptCore)

Vorig gedrag in WebKit:

  • Maak een string voor elke tag.
  • Voeg een gemaakte string toe aan Vector<string> en parseer de DOM-boom.
  • Na het parsen wordt een tekenreeks toegewezen waarvan de grootte de som is van alle tekenreeksen in Vector<string> .
  • Voeg alle strings in Vector<string> samen en retourneer deze als innerHTML .

Nieuw gedrag in WebKit: 1. Wijs één string toe, bijvoorbeeld S. 1. Voeg voor elke tag een string toe aan S, waarbij de DOM-boom stapsgewijs wordt geparseerd. 1. Retourneer S als innerHTML .

Kort gezegd komt het erop neer dat de patch niet een groot aantal strings aanmaakt en deze vervolgens aan elkaar koppelt, maar dat er één string wordt aangemaakt en dat de strings vervolgens stapsgewijs worden toegevoegd.

Verbeter de prestaties van div.innerText en div.outerText in Chromium/Mac met 4x (V8/Mac)

De patch heeft alleen de initiële buffergrootte voor het aanmaken van innerText gewijzigd. Het wijzigen van de initiële buffergrootte van 2^16 naar 2^15 verbeterde de prestaties van Chromium/Mac met een factor 4. Dit verschil is afhankelijk van het onderliggende malloc-systeem.

Verbeter de prestaties van CSS-eigenschapstoegang in JavaScriptCore met 35%

Een CSS-eigenschapstring (bijv. .fontWeight , .backgroundColor ) wordt in WebKit omgezet naar een integer-ID. Deze conversie is een zware klus. De patch cachet de conversieresultaten in een map (d.w.z. een eigenschapstring => een integer-ID), zodat de conversie niet meerdere keren wordt uitgevoerd.

Hoe werken de testen?

Ze meten de tijd die nodig is om toegang te krijgen tot de eigenschap. In het geval van innerHTML (de performancetest in bugs.webkit.org/show_bug.cgi?id=81214 ) meet de test alleen de tijd die nodig is om de volgende code uit te voeren:

for (var i = 0; i < 1000000; i++)
    document.body.innerHTML;

De prestatie-test gebruikt een groot lichaam dat is gekopieerd uit de HTML-specificatie.

Op vergelijkbare wijze meet de CSS-eigenschapstoegangstest de tijd van de volgende code:

var spanStyle = span.style;
for (var i = 0; i < 1000000; i++) {
    spanStyle.invalidFontWeight;
    spanStyle.invalidColor;
    spanStyle.invalidBackgroundColor;
    spanStyle.invalidDisplay;
}

Het goede nieuws is dat Kentaro Hara denkt dat er nog meer prestatieverbeteringen mogelijk zijn voor andere belangrijke DOM-kenmerken en -methoden.

Kom maar op!

Hulde aan Haraken en de rest van het team.