Comment testez-vous les performances du code JavaScript?
Cycles de processeur, utilisation de la mémoire, durée d'exécution, etc.?
Ajouté: Existe-t-il un moyen quantitatif de tester les performances en JavaScript en plus de la simple perception de la vitesse d'exécution du code?
Les profileurs sont certainement un bon moyen d'obtenir des chiffres, mais d'après mon expérience, la performance perçue est tout ce qui compte pour l'utilisateur/client. Par exemple, nous avons eu un projet avec un accordéon Ext qui s'est développé pour afficher certaines données, puis quelques grilles Ext imbriquées. En réalité, le rendu était assez rapide, aucune opération ne prenait longtemps, il y avait juste beaucoup d'informations qui étaient rendues en une seule fois, donc c'était lent pour l'utilisateur.
Nous avons "corrigé" cela, non pas en passant à un composant plus rapide, ni en optimisant une méthode, mais en affichant d'abord les données, puis en rendant les grilles avec setTimeout. Ainsi, les informations sont apparues en premier, puis les grilles se mettraient en place une seconde plus tard. Dans l’ensemble, le traitement de cette manière a pris un peu plus de temps, mais pour l’utilisateur, les performances perçues ont été améliorées.
De nos jours, le profileur Chrome et d'autres outils sont universellement disponibles et faciles à utiliser, de même que console.time() , console.profile() et performance.now() . Chrome vous donne également une vue de la chronologie qui peut vous montrer ce qui tue votre fréquence d'images, l'endroit où l'utilisateur pourrait attendre, etc.
Il est très facile de trouver de la documentation pour tous ces outils, vous n'avez pas besoin d'une réponse SO pour cela. 7 ans plus tard, je répète toujours le conseil de ma réponse initiale et signale qu'il est possible d'exécuter un code lent pour toujours, lorsqu'un utilisateur ne le remarquera pas, et un code assez rapide s'exécutant à l'endroit où ils le font, et ils se plaindront du code assez rapide ne pas être assez rapide. Ou que votre demande à l'API de votre serveur ait pris 220 ms. Ou quelque chose d'autre comme ça. Il reste que si vous sortez un profileur et que vous cherchez un travail, vous le trouverez, mais ce n'est peut-être pas le travail dont vos utilisateurs ont besoin.
Je conviens que la performance perçue est vraiment tout ce qui compte. Mais parfois, je veux juste savoir quelle méthode pour faire quelque chose est plus rapide. Parfois, la différence est énorme et mérite d'être connue.
Vous pouvez simplement utiliser des timers javascript. Mais je reçois généralement des résultats beaucoup plus cohérents en utilisant les méthodes natives Chrome (maintenant également dans Firefox et Safari) devTool console.time() & console.timeEnd()
Exemple d'utilisation:
var iterations = 1000000;
console.time('Function #1');
for(var i = 0; i < iterations; i++ ){
functionOne();
};
console.timeEnd('Function #1')
console.time('Function #2');
for(var i = 0; i < iterations; i++ ){
functionTwo();
};
console.timeEnd('Function #2')
Mise à jour (04/04/2016):
Chrome Canary a récemment ajouté Profil de niveau de ligne l'onglet sources des outils de développement, qui vous permet de voir exactement le temps qu'il a fallu à chaque ligne pour s'exécuter! 
On peut toujours mesurer le temps pris par n'importe quelle fonction par un simple objet de date.
var start = +new Date(); // log start timestamp
function1();
var end = +new Date(); // log end timestamp
var diff = end - start;
Essayez jsPerf . Il s'agit d'un outil de performance javascript en ligne permettant d'analyser et de comparer des extraits de code. Je l'utilise tout le temps.
La plupart des navigateurs implémentent maintenant la synchronisation haute résolution dans performance.now(). Il est supérieur à new Date() pour les tests de performances car il fonctionne indépendamment de l'horloge système.
Utilisation
var start = performance.now();
// code being timed...
var duration = performance.now() - start;
Références
JSLitmus est un outil léger pour la création de tests de performances JavaScript ad hoc.
Laissons examiner la performance entre function expression et function constructor:
<script src="JSLitmus.js"></script>
<script>
JSLitmus.test("new Function ... ", function() {
return new Function("for(var i=0; i<100; i++) {}");
});
JSLitmus.test("function() ...", function() {
return (function() { for(var i=0; i<100; i++) {} });
});
</script>
Ce que j'ai fait ci-dessus est de créer un function expression et function constructor effectuant la même opération. Le résultat est le suivant:
Résultat de performance FireFox
Résultat de performance IE
Certaines personnes suggèrent des plug-ins et/ou des navigateurs spécifiques. Je ne le ferais pas car ils sont vraiment vraiment utiles pour cette plate-forme unique; un test exécuté sur Firefox ne se traduira pas avec précision par IE7. Considérant que 99,999999% des sites ont plus d'un navigateur qui les visite, vous devez vérifier les performances sur toutes les plateformes populaires.
Ma suggestion serait de garder cela dans le SC. Créez une page d'analyse comparative avec tous vos tests JS et la date d'exécution. Vous pourriez même avoir AJAX-poster les résultats à vous pour le garder entièrement automatisé.
Ensuite, il suffit de rincer et de répéter sur différentes plateformes.
J'ai un petit outil où je peux rapidement lancer de petits cas de tests dans le navigateur et obtenir immédiatement les résultats:
Vous pouvez jouer avec du code et découvrir quelle technique est la meilleure dans le navigateur testé.
Je pense que les tests de performance JavaScript (temps) sont largement suffisants. J'ai trouvé un article très pratique sur test de performance JavaScript ici .
Voici une fonction simple qui affiche le temps d'exécution d'une fonction transmise:
var perf = function(testName, fn) {
var startTime = new Date().getTime();
fn();
var endTime = new Date().getTime();
console.log(testName + ": " + (endTime - startTime) + "ms");
}
Vous pouvez utiliser ceci: http://getfirebug.com/js.html . Il a un profileur pour JavaScript.
Réponse rapide
Sur jQuery (plus spécifiquement sur Sizzle), nous utilisons this (checkout master et open speed/index.html sur votre navigateur), qui utilise à son tour benchmark.js . Ceci est utilisé pour tester les performances de la bibliothèque.
Réponse longue
Si le lecteur ne connaît pas la différence entre benchmark, charge de travail et profileurs, lisez d’abord des bases de test de performance sur le section "readme 1st" de spec.org . Ceci est destiné aux tests système, mais la compréhension de ces bases aidera également les tests JS perf. Quelques faits saillants:
Qu'est-ce qu'un repère?
Un repère est "une norme de mesure ou d’évaluation" (Webster’s II Dictionary). Un benchmark informatique est généralement un programme informatique qui exécute un ensemble d'opérations strictement défini - une charge de travail - et renvoie une forme de résultat - une métrique - décrivant le fonctionnement de l'ordinateur testé. Les métriques de référence des ordinateurs mesurent généralement la vitesse: à quelle vitesse la charge de travail a-t-elle été complétée? ou débit: combien d'unités de charge de travail par unité de temps ont été terminées. L'exécution du même test de performance sur plusieurs ordinateurs permet d'effectuer une comparaison.
Devrais-je analyser ma propre application?
Idéalement, le meilleur test de comparaison des systèmes serait votre propre application avec votre propre charge de travail. Malheureusement, il est souvent impossible d'obtenir une large base de mesures fiables, reproductibles et comparables pour différents systèmes à l'aide de votre propre application avec votre propre charge de travail. Les problèmes peuvent inclure la génération d'un bon cas de test, des problèmes de confidentialité, une difficulté à assurer des conditions comparables, du temps, de l'argent ou d'autres contraintes.
Si ce n'est pas ma propre application, alors quoi?
Vous voudrez peut-être envisager d’utiliser des points de repère standardisés. Idéalement, une référence normalisée sera portable et aura peut-être déjà été exécutée sur les plates-formes qui vous intéressent. Cependant, avant d'examiner les résultats, vous devez être sûr de bien comprendre la corrélation entre vos besoins en matière d'applications/d'informatique et les le point de repère mesure. Les tests de performances sont-ils similaires aux types d'applications que vous exécutez? Les charges de travail ont-elles des caractéristiques similaires? En fonction de vos réponses à ces questions, vous pouvez commencer à comprendre comment le point de repère peut se rapprocher de votre réalité.
Remarque: un point de référence normalisé peut servir de point de référence. Néanmoins, lorsque vous effectuez une sélection de fournisseur ou de produit, SPEC ne prétend pas qu'un critère de référence normalisé peut remplacer l'analyse comparative de votre propre application réelle.
Test de performance JS
Idéalement, le meilleur test de performance consisterait à utiliser votre propre application avec votre propre charge de travail en changeant ce que vous devez tester: différentes librairies, machines, etc.
Si ce n'est pas faisable (et généralement ce n'est pas). La première étape importante: définir votre charge de travail. Cela devrait refléter la charge de travail de votre application. Dans cette discussion , Vyacheslav Egorov parle de charges de travail merdiques à éviter.
Vous pouvez ensuite utiliser des outils tels que benchmark.js pour vous aider à collecter des métriques, généralement la vitesse ou le débit. Sur Sizzle, nous souhaitons comparer l'impact des correctifs et des modifications sur les performances système de la bibliothèque.
Si quelque chose fonctionne vraiment mal, votre prochaine étape consiste à rechercher des goulots d'étranglement.
Comment trouver les goulots d'étranglement? Profilers
Quel est le meilleur moyen de profiler l'exécution de javascript?
Je trouve que le temps d'exécution est la meilleure mesure.
Vous pouvez utiliser console.profile dans firebug
X Profiler aborde ce problème du point de vue de l'utilisateur. Il regroupe tous les événements du navigateur, activités du réseau, etc. causés par une action de l'utilisateur (clic) et prend en compte tous les aspects tels que la latence, les délais d'attente, etc.
Voici une classe réutilisable pour la performance temporelle. L'exemple est inclus dans le code:
/*
Help track time lapse - tells you the time difference between each "check()" and since the "start()"
*/
var TimeCapture = function () {
var start = new Date().getTime();
var last = start;
var now = start;
this.start = function () {
start = new Date().getTime();
};
this.check = function (message) {
now = (new Date().getTime());
console.log(message, 'START:', now - start, 'LAST:', now - last);
last = now;
};
};
//Example:
var time = new TimeCapture();
//begin tracking time
time.start();
//...do stuff
time.check('say something here')//look at your console for output
//..do more stuff
time.check('say something else')//look at your console for output
//..do more stuff
time.check('say something else one more time')//look at your console for output
En général, je teste simplement les performances javascript, la durée d'exécution du script. jQuery Lover a donné un bon article lien pour tester performances du code javascript , mais l'article ne montre que comment tester combien de temps votre javascript le code s'exécute. Je recommanderais également la lecture d'un article intitulé "5 conseils sur améliorer votre code jQuery lorsque vous travaillez avec des ensembles de données énormes".
La règle d'or est de NE PAS, dans AUCUNE circonstance, verrouiller le navigateur de vos utilisateurs. Après cela, je regarde généralement le temps d'exécution, suivi de l'utilisation de la mémoire (à moins que vous ne fassiez quelque chose de fou, auquel cas cela pourrait être une priorité plus élevée).
C'est un bon moyen de collecter des informations sur les performances pour une opération spécifique.
start = new Date().getTime();
for (var n = 0; n < maxCount; n++) {
/* perform the operation to be measured *//
}
elapsed = new Date().getTime() - start;
assert(true,"Measured time: " + elapsed);