test de performance des opérations DOM via innerHTML

Question

Selon l'esprit de stackoverflow (grâce à @Bill le Lizard clarifiant cela) je voudrais présenter une petite recherche propre de la question bien connue de tous les développeurs web frontaux.

Comment obtenir de meilleures performances de jscript lors de la programmation de DHTML, en utilisant les opérations innerHTML ou DOM? Pour les tests, j'ai créé une seule page HTML avec le bouton "start test" qui exécute 5000 fois la paire de fonction, qui est écrit soit sur l'idéologie innerHTML, soit par DOM. (Il peut être pris sur: http://codepad.org/HyiKRsNk)

• Pour éviter comparer les résultats de CPU sont affichés en pour cent, comment la fonction est plus rapide puis un autre. Donc, si vous voyez (17%), cela signifie que DOM innerHTML est plus rapide, si (peut-être plus tard) vous voyez (-5%) c'est innerHTML plus rapide que DOM.
• Pour éviter l'explosion de la mémoire, pour chaque appel, une nouvelle "zone de test" est créée et supprimée immédiatement après le test (le temps de création/suppression n'est pas atteint).
• test sont effectuées en display: none div pour éviter le retournement et la dégradation des performances sur le défilement

J'ai préparé 3 test (le dernier proposé par @tomdemuyt)

1. créer de nouvelles DIV et texte enfant pour elle

2. supprimer certains dIV (pour éviter l'influence de la différence de création, les deux tests utilise même pour créer div test, mais différent pour enlever)

3. Ajout d'un gestionnaire d'événement onclick

4. Création d'un test d'arborescence en profondeur, création d'un test <table><tbody><tr><td><span>text. Le test DOM utilise des appels séquentiels de la paire createElement/appendChild

5. Similaire à (4) mais 2 lignes <tr> sont créées. DOM utilise la fonction d'aide spéciale pour simplifier:

   treeHelper("table", 
       treeHelper("tbody", 
        treeHelper("tr", 
   

Les résultats des tests sont suivis pour les différents navigateurs.

Alors, chers collègues, veuillez fournir: montrez un test quand innerHTML est plus rapide, lancez mon test sur les navigateurs non encore listés.

Answer 1

Opera (10,54):

Test        Result 
1.insert new element and text   30.00% 
2.removeChild vs innerHTML=''   66.67% 
3.set event handler     245.45% 
4.test in depth of tree linear  -62.16% 
5.test in depth of tree (using helpr) -67.10% 

Chrome (5.0.375.70):

Test         Result 
1.insert new element and text   318.18% 
2.removeChild vs innerHTML=''   53.85% 
3.set event handler     150.00% 
4.test in depth of tree linear   41.67% 
5.test in depth of tree (using helpr) -33.03% 

FireFox (3.6.4):

Test         Result 
1.insert new element and text   76.17% 
2.removeChild vs innerHTML=''   50.56% 
3.set event handler      1097.44% 
4.test in depth of tree linear   32.94% 
5.test in depth of tree (using helpr) 9.66% 

IE (8):

Test         Result 
1.insert new element and text   46.92% 
2.removeChild vs innerHTML=''   26.34% 
3.set event handler      936.17% 
4.test in depth of tree linear   -35.42% 
5.test in depth of tree (using helpr) -67.26% 

EDITED (1): ajouté pour chaque navigateur 2 lignes de test de la construction d'arbre en profondeur (test en profondeur de l'arbre linéaire , test en profondeur de l'arbre (en utilisant helpr)). Il a été découvert que la plupart des navigateurs n'aiment pas les valeurs d'allocation de pile, puisque appendChild linéaire, appendChild ... beaucoup plus rapide que la même chose sur treeHelper ('table', treeHelper ('tbody', ....

Answer 2

Basé sur les commentaires sur la question initiale j'ajoute ici une réponse qui développe pourquoi tout droit .innerHTML-DOM manipulation comparaison est très difficile d'évaluer de façon concise

Essentiellement, il y a quelques préoccupations majeures:.

1. Bugs de navigateur & implémentations manquantes
2. Différences de contenu (ce qui fonctionne mieux dans le cas A, ne peut pas être meilleur dans le cas B)
3. Problèmes de synchronisation (JavaScript n'a aucun contrôle ou insight sur le moment où le navigateur décide de faire GC (Garbage Collection) ou d'exécuter d'autres threads/activités

1.) En particulier IE (6,7 & dans une moindre mesure 8) a un tas de bugs de navigateur qui provoquent des tests complets de tous les scénarios de code. (IE dispose d'insectes et ne peut pas définir la .innerHTML sur un select, table, thead, tbody, tfoot, tr, des éléments vides avec ensemble de trop-plein pour automobiles où la teneur est supérieure à une « ligne » de hauteur, pre éléments où le contenu contient des espaces importants, etc.)

2.) La quantité, le type (ordre) et la profondeur des nœuds enfants ajoutés modifieront les performances de l'opération. Par exemple. ajouter une table en ajoutant l'étiquette de la table, puis un tbody, puis un tr, puis un td, puis le contenu contre la construction séparément et le dumping dans la page va modifier la performance. 3. Le navigateur contrôle quand il fait un GC (ce qui ralentira le navigateur pendant un certain temps pendant le nettoyage). De même, une extension de navigateur, ou appel AJAX dans un autre onglet, tranche Web dans IE8 interroge un serveur pour les mises à jour, il aura une incidence sur la façon dont votre page actuelle effectue.

Ainsi, si vous voulez tester complètement cela, vous devrez tester plusieurs combinaisons différentes de sous-structure HTML et je m'attendrais fortement à ce que les résultats varient.

J'ai quelques vieux tests pour ce genre de chose à la maison que je vais creuser et ajouter à cette réponse pour les tests plus impliqués.