L'analyse comparative par chronométrage est-elle acceptable?

Question

Quelqu'un a-t-il déjà utilisé l'analyse comparative de chronomètre ou un outil de performance devrait-il toujours être utilisé? Existe-t-il de bons outils gratuits disponibles pour Java? Quels outils utilisez-vous?

Pour clarifier mes inquiétudes, l'analyse comparative du chronomètre est sujette aux erreurs dues à la planification du système d'exploitation. Lors d’une exécution donnée de votre programme, le système d’exploitation peut planifier un autre processus (ou plusieurs) au milieu de la fonction que vous chronométrez. En Java, la situation est encore pire si vous essayez de chronométrer une application threadée, car le planificateur JVM ajoute encore un peu plus d’aléatoire au mélange.

Comment abordez-vous la planification du système d'exploitation lors de l'analyse comparative?

Answer 1

L'analyse comparative par chronomètre est acceptable, à condition que vous mesuriez suffisamment d'itérations pour être significatif. En règle générale, j'ai besoin d'un temps total écoulé de quelques secondes à un chiffre. Sinon, la planification et les autres interruptions O / S de votre processus biaiseront considérablement vos résultats.

Pour cela, j'utilise un petit ensemble de méthodes statiques que j'ai construites il y a longtemps et qui reposent sur System.currentTimeMillis () .

Pour le profilage, j’ai utilisé jProfiler pour un numéro. d'années et l'ont trouvé très bon. J'ai récemment consulté YourKit , ce qui semble très bien sur le site Web, mais je ne l'ai pas utilisé du tout. personnellement.

Pour répondre à la question sur les interruptions de planification, j’ai constaté que le fait de répéter plusieurs fois jusqu’à ce que la cohérence soit atteinte / que l’on observe fonctionne en pratique pour éliminer les résultats anormaux de la planification de processus. Je trouve également que la planification des threads n'a pas d'impact pratique pour des durées de 5 à 30 secondes. Enfin, une fois que vous avez dépassé le seuil fixé, l’ordonnancement de quelques secondes a, selon mon expérience, un impact négligeable sur les résultats - j’estime qu’un cycle de 5 secondes correspond en moyenne à la même durée qu’un cycle de 5 minutes pour le temps / itération.

Vous pouvez également envisager de pré-exécuter le code testé environ 10 000 fois pour "réchauffer". JIT, en fonction du nombre de fois où le code testé doit être exécuté dans la vie réelle.

Answer 2

C’est totalement valable tant que vous mesurez des intervalles de temps assez grands. Je voudrais exécuter 20-30 exécutions de ce que vous avez l'intention de tester pour que le temps total écoulé soit supérieur à 1 seconde. J'ai remarqué que les calculs de temps basés sur System.currentTimeMillis () ont tendance à être 0 ms ou ~ 30 ms; Je ne pense pas que vous puissiez obtenir quelque chose de plus précis que cela. Vous pouvez essayer System.nanoTime () si vous avez vraiment besoin de mesurer un petit intervalle de temps:

• documentation: http: / /java.sun.com/javase/6/docs/api/java/lang/System.html#nanoTime ()
• SO question de mesurer les petits délais, car System.nanoTime () pose également des problèmes: Comment puis-je mesurer le temps avec la microseconde précision en Java?

Answer 3

Un profileur vous fournit des informations plus détaillées pouvant vous aider à diagnostiquer et à résoudre les problèmes de performances.

En termes de mesure réelle, le temps de chronométrage est ce que les utilisateurs remarquent. Par conséquent, si vous souhaitez valider que les choses se situent dans des limites acceptables, le temps de chronométrage convient.

Toutefois, lorsque vous souhaitez réellement résoudre les problèmes, un profileur peut s'avérer très utile.

Answer 4

Le chronomètre est en fait le meilleur repère!

Le temps de réponse réel de l'utilisateur final est celui qui compte réellement.

Il n’est pas toujours possible d’obtenir cette heure à l’aide des outils disponibles. Par exemple, la plupart des outils de test n’incluent pas le temps nécessaire au navigateur pour restituer une page. Par conséquent, une page surcomplexée avec des CSS mal écrites affichera des temps de réponse inférieurs à la seconde. aux outils de test, mais 5 secondes plus le temps de réponse à l'utilisateur.

Les outils sont parfaits pour les tests automatisés et pour la détermination des problèmes, mais ne perdez pas de vue ce que vous voulez vraiment mesurer.

Answer 5

Vous devez tester un nombre réaliste d'itérations, car vous obtiendrez des réponses différentes en fonction de la manière dont vous testez le minutage. Si vous n'effectuez qu'une opération une fois, il peut être trompeur de prendre la moyenne de nombreuses itérations. Si vous souhaitez connaître le temps nécessaire après l’échauffement de la machine virtuelle, exécutez de nombreuses itérations (par exemple 10 000) qui ne figurent pas dans les timings.

Je vous suggère également d'utiliser System.nanoTime () car il est beaucoup plus précis. Si votre temps de test est d'environ 10 microsecondes ou moins, vous ne souhaitez pas l'appeler trop souvent, car cela pourrait modifier votre résultat. (Par exemple, si je teste pendant 5 secondes et que je veux savoir quand cela se produit, je n’obtiens que le nanoTime toutes les 1000 itérations, si je sais qu’une itération est très rapide)

Answer 6

  

Comment abordez-vous la planification du système d'exploitation lors de l'analyse comparative?

Indiquez si le temps nécessaire est suffisant pour un système représentatif de la machine que vous utiliserez. Si votre système d'exploitation ralentit votre application, cela devrait faire partie du résultat.

Inutile de dire que mon programme serait plus rapide si je n'avais pas de système d'exploitation.

Si vous utilisez Linux , vous pouvez utiliser des outils tels que numactl , chrt et tasket pour contrôler comment les processeurs sont utilisés et la planification.

Answer 7

Les profileurs peuvent entraver les chronométrages. J'utiliserais donc une combinaison de chronométrage par chronomètre pour identifier les problèmes de performances généraux, puis le profileur pour déterminer le moment où le temps est utilisé. Répétez le processus si nécessaire.

Answer 8

Après tout, c’est probablement la deuxième forme d’analyse comparative la plus populaire, juste après "l'analyse comparative" (no-watch benchmarking). - où nous disons "cette activité semble lente, celle-ci semble rapide".

Généralement, le plus important à optimiser est ce qui gêne l'expérience utilisateur - ce qui dépend le plus souvent de la fréquence à laquelle vous effectuez l'action et de tout ce qui se passe en même temps. D’autres formes d’analyse comparative permettent souvent de mieux cerner ces problèmes.

Answer 9

Je pense qu'une question clé est la complexité et la durée de l'opération.

J’utilise parfois même des mesures de chronomètre physique pour vérifier si quelque chose prend du temps en minutes, en jours, voire en semaines (je travaille avec une application où les temps d’exécution de plusieurs jours ne sont pas inconnus, même si et les minutes sont les durées les plus courantes).

Toutefois, l’automatisation offerte par les appels vers n’importe quel type de système d’horloge de l’ordinateur, comme l’appel java millis auquel il est fait référence dans l’article lié, est nettement supérieure à la vérification manuelle de la durée d’exécution.

Les profileurs sont bien, quand ils fonctionnent, mais j'ai eu du mal à les appliquer à notre application, ce qui implique généralement la génération de code dynamique, le chargement dynamique de DLL et le travail effectué dans les deux compilées juste à temps compilées langages de script de mon application. Ils se limitent souvent à une seule langue source et à d’autres attentes irréalistes pour des logiciels complexes.

Answer 10

J'ai lancé aujourd'hui un programme qui cherchait et collectait des informations à partir de plusieurs fichiers dBase. L'exécution ne prend qu'un peu plus de une heure . J’ai jeté un coup d’œil au code, j’ai deviné en connaissance de cause le goulet d’étranglement, j’ai apporté une légère amélioration à l’algorithme et ai relancé le programme, qui s’est achevé en 2,5 minutes .

Je n'ai pas eu besoin d'outils de profilage sophistiqués ni de suites de tests pour me dire que la nouvelle version constituait une amélioration significative. Si j'avais besoin d'optimiser davantage le temps d'exécution, j'aurais probablement fait une analyse plus sophistiquée, mais ce n'était pas nécessaire. Je trouve que ce type d'analyse comparative "chronomètre" est une solution acceptable dans un grand nombre de cas et le recours à des outils plus avancés prendrait en réalité plus de temps.

Answer 11

Je ne pense pas que l'analyse comparative par chronométrage soit trop horrible, mais si vous pouvez utiliser une machine Solaris ou OS X, vous devriez jeter un œil à DTrace. Je l'ai utilisé pour obtenir d'excellentes informations sur le minutage dans mes applications.

Answer 12

J'utilise toujours l'analyse comparative du chronomètre car c'est tellement plus facile. Les résultats n'ont cependant pas besoin d'être très précis pour moi. Si vous avez besoin de résultats précis, vous ne devriez pas utiliser l'analyse comparative du chronomètre.

Answer 13

Je le fais tout le temps. Je préférerais de loin utiliser un profileur, mais le fournisseur du langage spécifique au domaine avec lequel je travaille ne le fournit pas.