[JS] Enorme lappen HTML injecteren

[Bozozo]

Ik ben bezig aan een pic -> ASCII converter en ik loop tegen iets irritants aan. Ik maak nu gebruik van AJAX voor een wat snellere gebruikservaring zonder knipperen. Alles werkt prima... ik genereer de ascii met PHP en dan zet ik m in de juiste div met innerHTML = ...

Echter, als ik nu de ASCII kleurtjes geef (ieder symbool z'n eigen <span style="color: #aaaaaa">) dan wordt de pagina ontzettend traag. Ik dacht dat het aan mijn conversie algoritme lag, maar niets is minder waar. Voor een grote afbeelding is de conversie af in ongeveer een seconde. De hoeveelheid data is goed te overzien (honderden kb) maar dan duurt het een whopping 30 seconden om het innerHTML command uit te voeren. Als ik gewoon een nieuwe html pagina open (waar dus de nieuwe html al gewoon in de div staat) opent de pagina vele malen sneller.

Waarom is innerHTML injectie zo ontzettend veel trager dan gewoon een nieuwe pagina openen?

[ChessSpider]

Hoe precies gebruik je het innerHTML commando? Wat ik vond was dat het vele malen sneller was om de gegevens eerst op te slaan in een variabele, en dan als hij klaar is pas de variabele dmv innerHTML te laten weergeven. In plaats van de data zodra het binnenkwam elke keer met innerHTML te laten updaten.

[crisp]

Bozozo schreef op vrijdag 21 maart 2008 @ 23:51:
Waarom is innerHTML injectie zo ontzettend veel trager dan gewoon een nieuwe pagina openen?

In het laatste geval heb je voordeel van 'incremental-rendering'. Is het overigens browser-afhankelijk of niet? Het kan wel eens helpen om voordat je de innerHTML vult de parent tijdelijk een display:none te geven. Verder is IE notorieus traag met grote strings.

[ Voor 5% gewijzigd door crisp op 21-03-2008 23:58 ]

[Bozozo]

Ik doe gewoon divje.innerHTML = responsetext. Die truc met de display op none zetten kende ik niet, dat zal ik nog eens bekijken.

Voorlopig heb ik besloten heel AJAX maar even te vergeten. Het was niet cruciaal en zonder AJAX (zeg maar 'traditioneel') laadt de pagina in minder dan twee seconden. Daar kom je niet aan met trucjes denk ik.

Ik testte trouwens in Firefox. IE niet eens geprobeerd

[Bosmonster]

Is het niet sneller misschien om bijvoorbeeld een element aan te maken, daar de innerHTML van te zetten en dan het element in te voegen?

Zo zijn er nog wel meer dingetjes te bedenken die het mogelijk sneller maken.

[Bozozo]

Ik heb een geïsoleerde testpagina gemaakt en daar zijn wat leuke dingen uitgekomen:
- de display: none truc doet niks. Het commando wordt zelfs niet eens zichtbaar uitgevoerd als er een flinke lap innerHTML wordt geïnjecteerd... heel gek.
- een nieuw element creëren, daarvan de innerHTML zetten en dan dat element appenden is heel snel (orde 1 seconde voor een stevige lap html)
- firebug maakt je browser ongeveer 10% langzamer

Voorlopig ga ik AJAX niet meer implementeren, maar dit is toch fijn om te weten.

Voortaan dus nooit innerHTML direct zetten maar altijd een nieuw element appenden!

[_Thanatos_]

Is het echt HTML wat je aan het invoegen bent? If not, dan is het dus plaintext (lijkt me zo ) en kun je dus een text-node aanmaken:

JavaScript:

var text = document.createTextNode(asciiart);
containerofzo.appendChild(text);

Ofzo

[Bozozo]

Testcase online

Conclusie: het is een bug in firefox. Andere browsers zijn met beide methodes sneller, maar Firefox doet er echt belachelijk lang over om een lange string html rechtstreeks in een bestaande div te zetten.

Ik heb even geen tijd voor verdere uitleg, maar de broncode is duidelijk genoeg:
10.000 keer stukje html in nieuwe div als innerHTML injecteren en die div appenden
vs
1 x een lange string van 10.000 keer hetzelfde stukje html achter elkaar rechtstreeks als innerHTML injecteren.

[.oisyn]

Allebei 1 seconde hier in FF 2.0.0.12 op een Core 2 Duo 2.66 GHz

[MueR]

Op een Athlon64 3500+ doet de appendChild er zo'n 2 sec over, innerHtml zo'n 6 sec.

[crisp]

Hier op een AMD XP2000 onder win2k appendChild: 4 seconden, innerHTML 1 seconde

note dat je dit soort testen het beste onder een leeg profiel kan uitvoeren, extensies kunnen in veel gevallen voor onnodige vertraging zorgen.

[Bozozo]

Dan denk ik dat Web Developer Toolbar de schuldige is. Verder heb ik alleen een paar thema's en Firebug, maar die staat uit.

Ik overweeg nu zelf om van Firefox af te stappen... Safari en Opera zijn allebei duidelijk sneller, dat was me al eerder opgevallen bij zware javascripts.

[crisp]

Bozozo schreef op zondag 23 maart 2008 @ 11:55:
Dan denk ik dat Web Developer Toolbar de schuldige is. Verder heb ik alleen een paar thema's en Firebug, maar die staat uit.

Ik overweeg nu zelf om van Firefox af te stappen... Safari en Opera zijn allebei duidelijk sneller, dat was me al eerder opgevallen bij zware javascripts.

Firefox 3 al geprobeerd? Die is mbt core JS weer een stuk sneller dan Opera en Safari

[Civil]

Die innerHTML methode is ontzettend afhankelijk van het feit of je de pagina tussendoor reload of dat je een paar keer achter elkaar op de injectHTML knop klikt. Bij een lege pagina doet de appendChild methode er 3 seconden over terwijl de innerHTML methode er 0 seconde over doet. Maar ik heb ook een bijna vastloper gehad doordat ik de pagina niet gereload had (62 sec).

Firefox 2.0.0.12 onder Vista op een DUAL CPU 1.60Ghz / 2.40GHz laptop.

[Bozozo]

Ik heb de schuldige inmiddels gevonden. Ik heb al mijn extensies uitgeschakeld. Firebug blijkt de boel een klein beetje vertragen maar het is niet de veroorzaker van de vertraging. Het blijkt een hele maffe bug in Firefox te zijn. Het probleem is de Foutconsole.

Hieronder een tabelletje met rekentijden voor de testcase. Tijden in afgeronde seconden rekentijd op een Intel Pentium M 1.86 GHz.

	IE 7	FF 2	FF 2 + FC bug	Safari 3	Opera 9
appendChild	3	2	2	0	1
innerHTML	1	3	34	0	1

Als je de pagina opent en de beide methodes een keer draait zie je geen vreemde tijden. Firefox is sowieso vrij traag maar à la. Als je dan de foutconsole opent en weer sluit, en dan nogmaals de beide methodes draait, dan zie je dat de rekentijd voor de innerHTML methode is ontploft.

Het openen van de foutconsole lijkt de afhandeling van Javascript te beïnvloeden

[Bosmonster]

Zelfs zonder foutconsole is die bij mij de tweede run gewoon veel en veel trager. Eerste keer gaat het wel, tweede keer loopt ie bijna vast.

Hetzelfde gebeurt overigens in Safari 3.1 voor Windows. Als ik twee keer klik dan crasht de boel.

[ Voor 26% gewijzigd door Bosmonster op 23-03-2008 15:24 ]

[Bozozo]

Vreemd. In Safari 3.0.4 (win) doet ie beide methodes in 1 seconde.

[M55]

WinXP( FF3b4 ) duurt innerHTML zo'n 12 sec (FB uit) en met FC (FB uit) zelfs 60+ (!). Internet Explorer 6 doet er maar 1 sec over.

Dit op een trage Laptop met 2ghz Celeron.

[ Voor 14% gewijzigd door M55 op 24-03-2008 18:03 ]

[Arjan90]

Vista Business (32-bit)
FireFox 2.0.0.12

AppendChild: 13 seconden (2de keer 14 seconden)
InnerHTML: 24 seconden (2de keer 35 seconden)

Op een X2 4600+ (~2.7Ghz)

[M55]

Nogmaals geprobeerd op zelfde systeem:

1e keer FF InnerHTML: 3 sec.
2e keer FF InnerHTML: 47 sec.

[M55]

Als je onderstaande gebruikt in de 'else' lus
[javascript]
else {
document.body.removeChild(asciidiv);
asciidiv = document.createElement('div');
document.body.appendChild(asciidiv);
// asciidiv.innerHTML = '' blijkt traag te zijn.
asciidiv.innerHTML = str;
}
[/javascript]

Dan is het ook de tweede keer 'snel' in FF.

[ Voor 8% gewijzigd door M55 op 24-03-2008 19:21 ]