Pourquoi mon programme s'exécute-t-il beaucoup plus rapidement lorsque j'active le profilage ?

Question

J'ai un programme qui s'exécute assez lentement (il prend environ 20 secondes, même à la sortie de la version). Pour le réparer, j'ai essayé d'utiliser le profileur intégré de Visual Studio. Cependant, lorsque j'exécute le programme avec le profilage activé, il se termine en moins d'une seconde. Il est donc très difficile de trouver un goulot d'étranglement. Je posterais bien le code mais il est long. Y a-t-il des raisons évidentes ou moins évidentes pour lesquelles cela se produit ?

EDIT : Ok, j'ai réduit le problème à un tas d'appels free(). Quand je les commente, le programme s'exécute dans le même temps qu'avec le profilage activé. Mais maintenant j'ai une fuite de mémoire :-/

Answer 1

La raison en est que lorsque vous exécutez votre application dans Visual Studio, le débogueur y est attaché. Lorsque vous l'exécutez en utilisant le profileur, le débogueur n'est pas attaché.

Si vous appuyez sur F5 pour exécuter votre programme, même avec la version Release, le débogueur est toujours attaché.

Si vous essayez d'exécuter le fichier .exe par lui-même, ou d'exécuter le programme dans l'IDE avec "Debug > Start Without Debugging" (ou appuyez simplement sur Ctrl+F5), l'application devrait fonctionner aussi vite qu'avec le profileur.

Answer 2

Ça ressemble beaucoup à un Heisenbug .

Ils existent vraiment, et ils peuvent être douloureux à découvrir.

D'après mon expérience, la meilleure solution consiste à changer la façon dont vous établissez le profil -- éventuellement de plusieurs façons -- jusqu'à ce que le bug disparaisse.

Utilisez différents profileurs. Essayez d'ajouter du code de chronométrage au lieu d'utiliser un profileur.

Answer 3

L'activation du profileur aura pour effet de déplacer votre code (un peu), ce qui masquera probablement le problème.

La cause la plus courante des hiesenbugs est l'utilisation de variables non initialisées, la deuxième cause la plus courante est l'utilisation de la mémoire après qu'elle ait été libérée(). Puisque votre free semble résoudre le problème, vous pourriez penser à rechercher les références tardives, mais je rechercherais toujours les variables non initialisées en premier si j'étais vous.

Answer 4

Dans mon cas, c'était dû à la résolution de la minuterie de Windows.

Si votre programme utilise le threading, la résolution du System wide Timer peut être la raison de temps plus longs lors de l'exécution par Visual studio.

La résolution par défaut de la minuterie de Windows est de 15,6 ms.

Lorsqu'il est exécuté par le profileur, ce dernier fixe cette valeur à 1ms, ce qui accélère l'exécution. Regardez ceci réponse

Answer 5

La méthode générale serait de diviser pour mieux régner, c'est-à-dire de n'exécuter que certaines parties du programme et de voir si le problème disparaît. Mais il semble que vous l'ayez déjà fait. AFAIK free ne prend généralement pas beaucoup de temps, mais malloc peut prendre beaucoup de temps si la mémoire est fragmentée. Si vous n'appelez pas free(), le tas ne sera jamais fragmenté en premier lieu. (Un code de profilage intrusif pourrait empêcher la fragmentation de la mémoire en allouant de petits blocs de données et en remplissant les espaces libres - mais j'admets que c'est une explication un peu faible).

Peut-être pouvez-vous ajouter des appels manuels de mesure du temps avant/après les appels à malloc et new et imprimer les temps pour vérifier cela ? Peut-être pouvez-vous également analyser vos modèles d'allocation de mémoire pour savoir si vous avez un problème de fragmentation du tas (probablement en regardant le code et en faisant du débogage symbolique dans votre tête ;-)