Comment testez-vous le code JavaScript?
Cycles CPU, utilisation de la mémoire, temps d'exécution, etc.?
Ajouté: y a-t-il une façon quantitative de tester les performances en JavaScript en dehors de la simple perception de la vitesse à laquelle le code s'exécute?
19 réponses
profileurs sont certainement un bon moyen d'obtenir des nombres, mais dans mon expérience, la performance perçue est tout ce qui importe à l'utilisateur/client. Par exemple, nous avons eu un projet avec un accordéon Ext qui s'est étendu pour montrer quelques données et puis quelques grilles Ext imbriquées. Tout s'est en fait rendu assez rapidement, aucune opération n'a pris beaucoup de temps, il y avait juste beaucoup d'informations rendues en même temps, donc cela a semblé lent à l'utilisateur.
passer à un composant plus rapide, ou optimiser une méthode, mais en rendant les données d'abord, puis en rendant les grilles avec un setTimeout. Donc, l'information est apparue en premier, puis les grilles ont surgi en place une seconde plus tard. Dans l'ensemble, il a fallu un peu plus de temps de traitement pour le faire, mais pour l'utilisateur, la performance perçue a été améliorée.
EDIT: la réponse est maintenant âgé de 7 ans. De nos jours, le profileur Chrome et d'autres outils sont universellement disponibles et faciles à utiliser, comme le sont console.time() , console.profile() , et performance.now() . Chrome vous donne également une vue de ligne de temps qui peut vous montrer ce qui tue votre cadence, où l'utilisateur pourrait être en attente, etc.
trouver de la documentation pour tous ces outils est vraiment facile, vous n'avez pas besoin d'une réponse si pour cela. 7 ans plus tard, je vais encore répéter le Conseil de ma réponse originale et soulignez que vous pouvez avoir le code lent courir pour toujours où un utilisateur ne le remarquera pas, et le code assez rapide courant où ils le font, et ils se plaindront du code assez rapide n'étant pas assez rapide. Ou que votre requête à votre API de serveur a pris 220ms. Ou quelque chose comme ça. Il n'en reste pas moins que si vous sortez un profileur et que vous cherchez du travail à faire, vous le trouverez, mais ce n'est peut-être pas le travail dont vos utilisateurs ont besoin.
je suis d'accord que la perception de la performance est vraiment tout ce qui compte. Mais parfois, je veux juste savoir quelle méthode de faire quelque chose est plus rapide. Parfois, la différence est énorme et vaut la peine d'être connue.
vous pouvez juste utiliser des minuteries javascript. Mais j'obtiens généralement des résultats beaucoup plus cohérents en utilisant le Chrome natif (maintenant aussi dans Firefox et Safari) méthodes 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 (4/4/2016):
Chrome canary a récemment ajouté profilage de niveau de ligne l'onglet Sources de dev tools qui vous permet de voir exactement combien de temps chaque ligne a pris à exécuter!
On peut toujours mesurer le temps pris par n'importe quelle fonction par simple objet date .
var start = +new Date(); // log start timestamp
function1();
var end = +new Date(); // log end timestamp
var diff = end - start;
la plupart des navigateurs implémentent maintenant le chronométrage haute résolution dans performance.now() . Il est supérieur au new Date() pour les tests de performance car il fonctionne indépendamment de l'horloge du 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 d'ad-hoc JavaScript tests de référence
examinons 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:
FireFox Résultat De Performance
IE Résultat de Performance
certaines personnes suggèrent des plug-ins et/ou des navigateurs spécifiques. Je ne le ferais pas parce qu'ils sont seulement vraiment utile pour cette plate-forme; un essai sur Firefox ne se traduira pas avec précision à IE7. Considérant 99.999999% des sites ont plus d'un navigateur les visiter, vous devez vérifier les performances sur toutes les plates-formes populaires.
ma suggestion serait de garder ceci dans le JS. Créer une page de benchmarking avec tous votre test JS sur et l'Heure de l'exécution. Vous pouvez même L'avoir AJAX-post les résultats de nouveau à vous pour le garder entièrement automatisé.
ensuite, il suffit de rincer et de répéter sur différentes plates-formes.
j'ai un petit outil où je peux rapidement de petits cas de test dans le navigateur et obtenir immédiatement les résultats:
Vous pouvez jouer avec le code et savoir quelle technique est la meilleure dans le navigateur testé.
je pense que le test de performance JavaScript (temps) est tout à fait suffisant. J'ai trouvé un article très pratique sur JavaScript performance testing ici .
vous pouvez utiliser ceci: http://getfirebug.com/js.html . Il a un profileur pour JavaScript.
Voici une fonction simple qui affiche le temps d'exécution d'une fonction passée:
var perf = function(testName, fn) {
var startTime = new Date().getTime();
fn();
var endTime = new Date().getTime();
console.log(testName + ": " + (endTime - startTime) + "ms");
}
réponse Rapide
sur jQuery (plus spécifiquement sur Sizzle), nous utilisons ce (checkout master et open speed/index.html sur votre navigateur), qui à son tour utilise benchmark.js . Ceci est utilisé pour tester les performances de la bibliothèque.
longue réponse
si le lecteur ne connaît pas la différence entre le benchmark, la charge de travail et profileurs, d'abord lu quelques fondations d'essai de performance sur le "readme 1er" la section de spec.org . Ceci est pour tester le système, mais comprendre ces fondements aidera js perf test aussi bien. Quelques faits saillants:
Qu'est-ce qu'un indice de référence?
Un indice de référence est "une norme de mesure ou d'évaluation" (Webster's II Dictionnaire). Un ordinateur de référence est généralement un ordinateur programme qui exécute un ensemble strictement défini d'opérations - une charge de travail - et renvoie une forme de résultat - une métrique - décrivant comment l'ordinateur testé effectué. Les paramètres informatiques de référence mesurent habituellement la vitesse: la vitesse à laquelle la charge de travail a été remplie; ou le débit: le nombre d'unités de charge de travail par unité de temps. Exécutant le même ordinateur de référence sur plusieurs ordinateurs permet une comparaison.
dois-je évaluer ma propre demande?
idéalement, le meilleur test de comparaison pour les 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 en utilisant votre propre application avec votre propre charge de travail. Les problèmes peuvent inclure la production d'un bon cas type, des préoccupations de confidentialité, la difficulté à assurer des conditions comparables, le temps, l'argent, ou d'autres contraintes.
Si pas de ma propre application, alors quoi?
vous pouvez envisager d'utiliser des points de repère normalisés comme point de référence. Idéalement, un benchmark standardisé sera portable, et peut-être déjà utilisé sur les plateformes qui vous intéressent. Toutefois, avant de considérer les résultats, vous devez vous assurer de comprendre la corrélation entre vos besoins en matière d'application/de calcul et ce que le benchmark mesure. Être les benchmarks similaires aux types d'applications que vous utilisez? Les charges de travail ont-elles des caractéristiques semblables? En vous basant sur vos réponses à ces questions, vous pouvez commencer à voir comment le benchmark peut se rapprocher de votre réalité.
Note: un indice de référence normalisé peut servir de point de référence. Néanmoins, lorsque vous faites la sélection d'un fournisseur ou d'un produit, SPEC ne prétend pas qu'un benchmark standardisé puisse remplacer l'étalonnage de votre propre application.
tests de Performance JS
idéalement, le meilleur test de perf serait d'utiliser votre propre application avec votre propre charge de travail commutation ce que vous avez besoin de tester: différentes bibliothèques, machines, etc.
si cela n'est pas faisable (et ce n'est généralement pas le cas). La première étape: définir votre charge de travail. Il doit refléter la charge de travail de votre demande. Dans cette conversation , Vyacheslav Egorov parle sur les charges de travail merdiques que vous devriez éviter.
alors, vous pourriez utiliser des outils comme benchmark.js pour vous aider à recueillir des mesures, généralement la vitesse ou le débit. Sur Sizzle, nous sommes intéressés à comparer comment les corrections ou les changements affectent la performance systémique de la bibliothèque.
si quelque chose fonctionne vraiment mal, votre prochaine étape est de chercher des goulots d'étranglement.
Comment trouver des goulets d'étranglement? Profileurs
Quelle est la meilleure façon de profiler l'exécution javascript?
d'habitude, je teste juste les performances javascript,la durée du script. jQuery Lover a donné un bon lien d'article pour le test performance du code javascript , mais l'article montre seulement comment tester combien de temps votre code javascript fonctionne. Je recommande également la lecture de l'article intitulé "5 conseils sur améliorer votre code jQuery tout en travaillant avec des ensembles de données énormes".
UX Profiler aborde ce problème du point de vue de l'utilisateur. Il regroupe tous les événements du navigateur, l'activité du réseau, etc causé par une certaine action de l'utilisateur (clic) et prend en considération tous les aspects comme la latence, les temps morts, etc
la règle d'or est de ne pas verrouiller votre navigateur en aucune circonstance. Après cela, je regarde habituellement le temps d'exécution, suivi par l'utilisation de la mémoire (à moins que vous ne fassiez quelque chose de fou, dans ce cas, il pourrait être une priorité plus élevée).
il s'agit d'une bonne façon de recueillir de l'information sur le rendement pour l'opération en question.
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);
Voici une classe réutilisable pour la performance temporelle. Exemple 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