Débogage visuel à l'aide de >>,>,> |, ||, | <, <, <<

Question

Le débogage des problèmes de performance à l'aide d'un débogueur standard est presque sans espoir puisque le niveau de détail est trop élevé. D'autres façons utilisent un profileur, mais ils me donnent rarement de bonnes informations, surtout quand il y a une interface graphique et des threads d'arrière-plan, car je ne sais jamais si l'utilisateur attendait réellement l'ordinateur, ou pas. Une façon différente consiste simplement à utiliser Control + C et à voir où s'arrête le code.

Ce que je voudrais vraiment, c'est d'avoir une fonctionnalité Avance rapide, Lecture, Pause et Rembobinage combinée à une répression visuelle du code. Cela signifie que je pourrais définir le code pour exécuter Fast Forward jusqu'à ce que je navigue sur l'interface graphique vers le point critique. Ensuite, je mets le code à exécuter en mode lent, pendant que je reçois une répres- sion visuelle, quelles lignes sont en cours d'exécution (éventuellement une sorte de vue agrandie du code). Je pourrais par exemple définir la vitesse d'exécution à quelque chose comme 0.0001x. Je crois que j'aurais une très bonne visualisation de cette façon si le problème est à l'intérieur d'un module spécifique, ou peut-être dans la communication entre les modules.

Est-ce que cela existe? Mon besoin spécifique est en Python, mais je serais intéressé à voir une telle fonctionnalité dans n'importe quelle langue.

Answer 1

La fonction "Fast Forward to critical spot" existe déjà dans n'importe quel débogueur, elle s'appelle un "breakpoint". Il y a en effet des débogueurs qui peuvent ralentir l'exécution, mais cela ne vous aidera pas à déboguer les problèmes de performances, car cela ne ralentit pas l'ordinateur. Le processeur, le disque et la mémoire sont toujours aussi lents qu'auparavant, tout ce qui arrive est que le débogueur insère des délais entre chaque ligne de code. Cela signifie que chaque ligne de code prend soudainement plus ou moins le même temps, ce qui signifie qu'elle cache toute trace du problème de performance. La seule façon de trouver les problèmes de performance est d'enregistrer chaque appel effectué dans l'application et combien de temps cela a pris. C'est ce qu'un profileur fait. En effet, utiliser un profiler est délicat, mais il n'y a probablement pas de meilleure option. En théorie, vous pouvez enregistrer chaque appel et le moment de chaque appel, puis le lire et le reculer avec un rembobinage, mais cela nécessiterait une quantité de mémoire étonnante, et cela ne vous dirait rien de plus qu'un profiler (en effet, il vous en dirait moins, car il manquerait certains types de problèmes de performance).

Vous devriez être capable, avec le profiler, de comprendre ce qui prend beaucoup de temps. Notez que cela peut être à la fois par certains appels de fonction prenant beaucoup de temps, car ils font beaucoup de traitement, ou il peut être des appels système qui prennent beaucoup de temps devient quelque chose (réseau/disque) est lent. Ou peut-être qu'un appel très rapide est appelé charges et charges de temps. Un profileur vous aidera à comprendre cela. Mais cela aide si vous pouvez activer le profileur juste sur la section critique (réduit le bruit) et si vous pouvez exécuter cette section critique plusieurs fois (améliore la précision).

Answer 2

Je suppose qu'il y a une phase dans l'exécution de l'application qui prend trop de temps, c'est-à-dire qu'elle vous fait attendre. Je suppose que ce que vous voulez vraiment est de voir ce que vous pouvez changer pour le rendre plus rapide. Une technique qui fonctionne est random-pausing. Vous exécutez l'application sous le débogueur, et dans la partie de son exécution qui vous fait attendre, mettre en pause, et examiner la pile des appels. Fais le quelques fois.

Voici quelques façons que votre programme pourrait passer plus de temps que nécessaire.

• E/S que vous ne connaissiez pas et dont vous n'aviez pas vraiment besoin.
• Allocation et libération d'objets très fréquemment.
• Notifications d'emballement sur les structures de données.
• autres, trop nombreux à mentionner ...

Peu importe ce qu'elle est, quand il se produit, un examen de la pile d'appel le montreront. Une fois que vous savez ce que c'est, vous pouvez trouver une meilleure façon de le faire, ou peut-être ne pas le faire du tout.

Si le programme prend 5 secondes alors que cela peut prendre 1 seconde, la probabilité que le problème apparaisse à chaque pause est de 4/5. En fait, tout appel de fonction que vous voyez sur plus d'un échantillon de pile, si vous pouvez éviter de le faire, vous donnera une accélération significative. ET, presque tous les goulots d'étranglement possibles peuvent être trouvés de cette façon. Ne pas penser à la synchronisation des fonctions ni au nombre de fois où elles sont appelées. Cherchez les lignes de code qui apparaissent souvent sur la pile et dont vous n'avez pas besoin. Exemple ajouté: Si vous prenez 5 échantillons de la pile, et qu'il y a une ligne de code apparaissant sur 2 d'entre eux, alors il est responsable d'environ 2/5 = 40% du temps, donne ou de prendre. Vous ne connaissez pas le pourcentage exact, et vous n'avez pas besoin de savoir. (Techniquement, en moyenne c'est (2 + 1)/(5 + 2) = 3/7 = 43%, pas mal, et vous savez exactement où il se trouve.)

Answer 3

Les méthodes que vous décrivez, et beaucoup de commentaires me semblent être des tentatives probabilistes relativement faibles pour comprendre l'impact sur les performances. Les profileurs fonctionnent parfaitement bien pour les interfaces graphiques et les autres programmes inactifs, même s'il faut un peu de pratique pour les lire. Je pense que votre meilleur pari est là, cependant - apprendre à mieux utiliser le profileur, c'est à ça que ça sert.

L'utilisation spécifique que vous décrivez consiste simplement à attacher le profileur mais n'enregistre pas encore. Naviguez dans l'interface graphique jusqu'au point en question. Appuyez sur le bouton d'enregistrement du profileur, effectuez l'action et arrêtez l'enregistrement. Voir les résultats Réparer. Refais-le.