Je veux calculer la quantité de processeur de la CPU ma fonction prend pour exécuter en Java. Actuellement, je fais comme ci-dessous.
long startTime = System.currentTimeMillis(); myfunction(); long endTime = System.currentTimeMillis(); long searchTime = endTime - startTime;
5 Réponses :
Vous pouvez rechercher votre réponse ici: P>
Oui mais aucun qui répond à sa question sur la manière de mesurer le «temps de la CPU».
Il existe un certain nombre de profilés (JProfile, JPROBE, YOUKIT) disponibles pour analyser de telles données. Et non seulement cela, mais beaucoup plus ... (comme l'utilisation de la mémoire, les détails du fil, etc.) p>
system.currenttimemillis () code> ne mesurera que heure murale A>, jamais le temps de la CPU. Li>
- si em> vous avez besoin de temps mural, puis
system.nanotime () code>
est souvent plus précis (et jamais pire) que actueltimemillis () code>. < / li>
-
Threadmxbean.getthreadCuTime () code>
peut vous aider à déterminer combien de temps de processeur a utilisé un thread donné. Utilisez GestionFactory .getthreadmxbean () code>
pour obtenir un threadmxbean code> et thread.getid () code>
pour trouver le ID code> du fil que vous êtes intéressé par. Notez que cette méthode n'a pas besoin d'être prise en charge sur chaque JVM! LI>
ol>
Si je comprends bien le Javadoc correctement, System.Currenttimemillis () code>
pourrait également changer soudainement lorsque le temps système est modifié. Par conséquent, je pense System.NanOtime () code>
doit toujours être préféré sur System.Currenttimemillis () code> pour mesurer le temps écoulé.
Alors que la JVM réchauffe la quantité de temps prise variera. La deuxième fois que vous courez, cela sera toujours plus rapide que le premier. (La première fois qu'il doit charger des classes et appelez des blocs statiques) après avoir exécuté la méthode 10 000 fois, il sera plus rapide (le seuil par défaut auquel il compile le code de la machine natif)
Pour obtenir un timing moyen reproductible Pour une micro-repère, je vous suggère d'ignorer les 10 000 premières itérations et de l'exécuter pendant 2 à 10 secondes après cela. P>
par exemple par exemple p> très important : Seulement faire une de ces boucles par méthode. En effet, il optimise toute la méthode basée sur la manière dont elle est utilisée. Si vous avez une boucle occupée comme celle-ci, les boucles ultérieures sembleront plus lentes car elles n'ont pas couru et seront mal optimisées. P> P>
La question portait sur le "temps exact du processeur passé", cette réponse concerne l'horloge murale écoulée, comme en détail la réponse de Joachim Sauer. Celui-ci a de bonnes notes si WallClock-Time est la préoccupation, bien sûr.
Comme indiqué ci-dessus, cette réponse inclura chaque fois que votre thread dépendra en pause, par exemple pendant la GC, et ce n'est donc pas un bon moyen de faire des comparaisons de performances relatives et ne répond pas à la question qui précise l'heure de la CPU.
Cela signifie-t-il que JIT compilera la méthode 10 000 fois? Et après cela, cela ne le fera plus, il sera donc plus rapide? Merci
La bonne façon de faire des microbenchmarks est d'apprendre et d'utiliser correctement le Java MicobenchMark Harness (JMH) , qui est augmenté par le JEP 230 Microbenchmmmmmmmmmmmark de OpenJDK 12 en avant. Une recherche de "Java JMH" donnera des liens vers certains tutoriels utiles. J'ai aimé Blog de Jakob Jenkov , et bien sûr quoi que ce soit par La benchmarking Java est tout sauf trivial et moins votre code testé, le trou de lapin plus profond. L'horodatage peut être très trompeur lorsque vous essayez d'obtenir une adhérence sur les problèmes de performance. Le seul endroit où l'horodatage fonctionne est lorsque vous essayez de mesurer le temps d'attente pour des événements externes (comme l'attente d'une réponse à une requête HTTP et de ces types de choses), tant que vous pouvez vous assurer qu'il y a du temps négligeable entre le Débloquer un fil d'attente et la prise de l'horodatage "après", et tant que le fil est débloqué dûment en premier lieu. C'est typiquement le cas si, et seulement si, l'attente est au moins dans l'ordre des dizaines de millisecondes. Vous êtes bon si vous attendez secondes em> sur quelque chose. Néanmoins, les effets d'échauffement et de cache se produiront et ruinent l'applicabilité de vos mesures à la performance du monde réel tous les jours. P>
en termes de mesure "Heure exacte de la CPU", on peut prendre l'approche comme indiqué par la réponse de Joachim Sauer. Lorsque vous utilisez JMH, on peut mesurer l'utilisation de la CPU à l'extérieur, puis la moyenne par rapport au nombre d'itérations mesurées, car cela inclura la surcharge de harnais que l'approche conviendra pour des mesures comparatives, mais ne convient pas à une "ma fonction xy, en moyenne , prend tel et tel nombre de secondes de processeur sur chaque itération de l'architecture de la CPU que j'ai utilisée. ". Sur une CPU moderne et JVM une telle observation est pratiquement impossible à faire. P>