Question

J'écris un simple jeu de dames en Java. Lorsque je passe la souris sur la carte, mon processeur atteint 50% (100% sur un cœur).

Je voudrais savoir quelle partie de mon code (en supposant que ce soit de ma faute) est exécutée pendant cette opération.

J'ai essayé le débogage, mais le débogage pas à pas ne fonctionne pas très bien dans ce cas.

Existe-t-il un outil qui puisse me dire où se situe mon problème? J'utilise actuellement Eclipse.

Était-ce utile?

La solution

Ceci s’appelle "profilage". Votre IDE en a probablement un: voir Profileurs Open Source en Java .

Autres conseils

Utilisez un profileur ( votre kit , par exemple)

.

Profiling? Je ne sais pas quel IDE vous utilisez, mais Eclipse a un profier décent et une liste de profileurs open-source est également disponible à l'adresse source java .

En résumé, profileurs vous indiquera quelle partie de votre programme est appelé combien de fois.

Je ne présente pas beaucoup mes programmes, je n’ai donc pas beaucoup d’expérience, mais j’ai joué avec le profileur IDE NetBeans lorsque je le testais. (J'utilise aussi généralement Eclipse. Je vais également examiner les fonctions de profilage dans Eclipse.)

Le profileur NetBeans vous indiquera quel thread était en cours d’exécution depuis combien de temps et quelles méthodes ont été appelées combien de temps, et vous fournira des graphiques à barres pour indiquer le temps que chaque méthode a pris. Cela devrait vous donner une idée de la méthode qui pose problème. Vous pouvez consulter le profileur Java qui l'EDI NetBeans fournit, si vous êtes curieux.

Le profilage est une technique généralement utilisée pour déterminer quelles parties d’un programme prennent beaucoup de temps d’exécution, ce qui permet d’évaluer si des optimisations seraient bénéfiques pour améliorer les performances d’un programme. .

Bonne chance!

1) C'est de votre faute:)

2) Si vous utilisez eclipse ou netbeans, essayez d’utiliser les fonctionnalités de profilage - cela devrait vous dire assez rapidement où votre code passe beaucoup de temps.

3) à défaut, ajoutez une sortie de console où vous pensez que la boucle interne se trouve - vous devriez pouvoir la trouver rapidement.

Oui, il existe de tels outils: vous devez profiler le code. Vous pouvez essayer TPTP dans eclipse ou peut-être essayer JProfiler . Cela vous permettra de voir comment on appelle et à quelle fréquence.

Utilisez un profileur. Il y a beaucoup de. Voici une liste: http://java-source.net/open-source/profilers. Par exemple, vous pouvez utiliser JIP , un profileur au format Java.

Clover donnera un bon rapport indiquant le nombre de hits pour chaque ligne et branche. Par exemple, cela line a été exécuté 7 fois.

Des plug-ins pour Eclipse, Maven, Ant et IDEA sont disponibles. Il est gratuit pour le logiciel libre , ou vous pouvez obtenir un licence d'évaluation de 30 jours .

Si vous utilisez Sun Java 6, les dernières versions de JDK sont fournies avec JVisualVM . dans le répertoire bin. Il s'agit d'un outil de surveillance et de profilage performant qui nécessitera très peu d'effort - vous n'avez même pas besoin de démarrer votre programme avec des paramètres spéciaux - JVisualVM répertorie simplement tous les processus java en cours d'exécution et vous choisissez celui avec lequel vous souhaitez jouer. .

Cet outil vous indiquera quelles méthodes utilisent tout le temps processeur.

Il existe de nombreux outils plus puissants, mais commencez par jouer avec un outil gratuit. Ensuite, lorsque vous lirez les autres fonctionnalités disponibles, vous découvrirez comment elles pourraient vous aider.

Il s'agit d'un problème typique du "processeur élevé".

Il existe deux types de problèmes de processeur élevés

a) Où le thread utilise-t-il 100% du processeur d'un coeur (Ceci est votre scénario)

b) L’utilisation du processeur est «anormalement élevée» lorsque nous exécutons certaines actions. Dans de tels cas, le processeur peut ne pas être à 100% mais sera anormalement élevé. Cela se produit généralement lorsque le code comporte des opérations gourmandes en ressources CPU, telles que l'analyse XML, la désérialisation de la sérialisation, etc.

Le cas (a) est facile à analyser. Lorsque vous rencontrez 100% du processeur, 5 à 6 vidages de threads dans un intervalle de 30 secondes. Recherchez un thread actif (dans l'état "exécutable") et faisant partie de la même méthode (vous pouvez en déduire que vous surveillez la pile de threads). Très probablement, vous verrez une 'attente occupée' (voir le code ci-dessous pour un exemple)

while(true){
  if(status) break;
  // Thread.sleep(60000); // such a statement would have avoided busy wait
}

Le cas (b) peut également être analysé à l’aide de vidages de threads pris à intervalles égaux. Si vous avez de la chance, vous pourrez trouver le code du problème. Si vous ne parvenez pas à identifier le code du problème à l'aide de la sauvegarde de thread. Vous devez avoir recours à des profileurs. D'après mon expérience, le profileur de YourKit est très bon.

J'essaie toujours d'abord avec les vidages de threads. Les profileurs ne seront que le dernier recours. Dans 80% des cas, nous pourrons identifier à l'aide de dumps de threads.

Vous pouvez également utiliser des scénarios de test JUnit et un outil de couverture de code pour certains composants courants du vôtre. S'il existe des composants qui appellent d'autres composants, vous verrez rapidement qu'ils sont exécutés beaucoup plus souvent.

J'utilise des scénarios de test Clover avec JUnit, mais pour Open-Source, j'entends que EMMA est très bon.

Dans le code à un seul thread, je trouve l’ajout de certaines instructions telles que:     System.out.println ("A:" + System.currentTimeMillis ()); est plus simple et aussi efficace que d’utiliser un profileur. Vous pouvez bientôt limiter la partie du code à l’origine du problème.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top