Bonjour,

je travaille sur un programme en C/C++ qui comporte des fuites mémoires et qui a besoins de bonnes perfs. J'aimerais donc utiliser un profiler qui corresponde à ces critères:
-gratuit
-utilisable sous Linux
-possède une interface graphique
-application autonome ou plug-in Eclipse
-si possible éviter de recompiler

Le seul que j'ai trouvé est Valgrind, et il n'a pas d'interface graphique. Il y a quelques front-end comme KCachegrind, mais ils sont pauvres en fonctionnalités.

Avez vous un outil à me conseiller?

Merci pour votre aide.

Qu'est ce qeu tu veux de plus comme fonctionnalite qui ne soit pas dans valgrind(callgrind/cachegrind)+kcachegrind ?

Avec KCachegrind, on voit juste le nombre d'appels et le temps d'exécution des fonctions; les autres fonctionnalités de Valgrind ne sont pas prises en charge.
Par ailleurs, j'aimerais avoir la consommation mémoire des différents objets, l'évolution dans le temps, ...

Il est difficile (pas possible ?) de definir la consommation en memoire des objets a cause de l'allocation dynamique. Si tu as une classe:
class A
{
int *p = new int[12]
};
tu ne peux pas dire que l'objet creer consomme 13 octets, parceque si ailleurs, tu partages le pointeur p avec quelqu'un d'autre, tu ne souhaite le compter qu'une seule fois. Tu peux savoir combien d'objet sont actuellement aloue en regardant al difference entre le nombre d'appel a un constructeur et le nombre d'appel au destructeur.

Donc il est difficile de dire plus que objet o consomme sizeof(o) octets...

Au sujet de l'evolution dans le temps, je en connais pas d'outils qui fait ca automatiquement en C (ou C++), mais l'approche du debugger de caml est peut etre envisageable : frequement tu fork et le fils entre en attente, tu peux alors obtenir les informations de chaque snapshot. Je suis bien conscient que ce n'est pas exactement ce que tu demande.

kcachegrind fonctionne avec cachegrind et callgrind. Les autres outils sont plus pour le debuggage que pour le profiling (de memoire).

je viens de regarder un peu plus. Il y a une option --dump-every-bb dans callgrind qui permet de faire des dump regulierement. Ca permet d'obtenir des information dans kcachegrind par interval de temps. Tu peux aussi faire des dumps juste avant certains appel de fonction --dump-before. L'affichage peut respecter le code couleur des appels de fonctino pour visualiser un peu mieux ce qui se passe.

C'est sur que ce n'est pas l'outil rever pour le job. Mais je n'en connait pas de meilleur qui ne soit pas taille pour une seule application.

Ce qui me gêne avec Valgrind, c'est que pour détecter les fuites mémoire par exemple, on doit passer par une ligne de commande, et les différents fichiers de résultats n'ont pas un affichage très clair c'est juste du texte.
L'idéal ça aurait été un truc intégré à Eclipse, mais ajouter le support du C++ à TPTP n'est pas dans leurs priorités. Enfin, apparemment je vais devoir me contenter de Valgrind.
Merci pour les réponses.

je ne sais pas comment fonctionne ton IDE, amis il sait certainement executer des scripts ou des cibles de makefiles, tu peux mettre l'appel a valgrind a cet endroit. Valgrind sait sortir son log sur un filedescriptor separe ou sur un fichier donne.

Apres je ne sais pas comment tu travaille mais, je ne traque pas les fuites/erreur memoire en meme temps que je profile mon application. donc ca ne me gene pas. Quand au peu de verbosite de valgrind, je m'en fout un peu parceque seule la premiere erreur memoire est pertinene, les erreurs qui suivent sont certainement des consequences de la premiere de toute facon. Donc je traite les erreurs en commencant par la premiere. Il est utile de savoir que l'on peut demander a valgrind d'arreter l'execution du programme et d'attacher un debugger quand il rencontre une erreur.

La priorité pour le moment ce sont les fuites mémoires. L'optimisation, ce sera pour plus tard quand le programme sera fini et stable. Mais je me suis dit tant qu'à y être autant prendre dès le début un outils que je pourrais réutiliser.

D'ailleurs niveau erreur mémoire, j'ai eu une erreur bizarre en utilisant un vector. Si j'appelle explicitement le destructeur ~vector(), j'ai droit à une erreur de corruption de la mémoire. Pourtant, il n'y a rien d'alloué dynamiquement dans le vector en question.

mmm, on n'appelle jamais les destructeurs explicitement en C++... Du coup, le compilo pourrait mettre des choses bizarre la dedans.

On peut appeller des destructeurs directement, c'est legal, mais dans des cas tres precis, et de maniere generale il est recommande de ne jamais le faire =) (Sauf si on a pas le choix et qu'on sait exactement ce qu'on fait, par exemple si on a appele le constructeur via un placement new).

mmm, merci de cette precision. Je pensais que lorsque l'on redefinissait new et delete, l'appel au constructeur et au destructeur etait fait par C++ apres la fonctoin new et au destructeur avant l'appel a delete.

Tu as aussi l'appel au destructeur en sortie de portée pour un objet alloué sur la pile. Mais c'est vrai que j'ai jamais vu un cas ou il était nécessaire d'appeler explicitement un destructeur.

Surtout qu'un objet ainsi détruit sur lequel on possède une référence, il risque d'être explosif si on fait quelque chose avec.

Par contre, on peut trouver des objets ayant des méthodes free() ou dispose(), appelée par le destructeur SI (et seulement SI) l'utilisateur ne l'a pas fait lui-même. Un système comparable à la gestion de la fermeture automatique d'un stream à la destruction.

Pour la question du thread, c'est dommage d'avoir tant de critère car visual studio est très équipé pour la détection des fuites.
Sinon je sais que depuis la 6.8 netbeans proposent par mal d'outils de profiling basés sur les outils de sun studio, mais je sais pas si c'est utilisable ailleurs que sous slowlaris. Peut être te renseigner dans cette direction si tu es à court d'idées.

J'avais moi aussi cherché des outils de profilage pour GNU c++, j'ai du en rester à GDB et ses gros rapports texte en ligne de commande, c'était franchement pas la joie.

Si tu trouves quelque chose, reviens nous dire.

intel propose quelques outils de profiling, payant mais avec trial (pour peu d utiliser une autre addresse email), par exemple http://software.intel.com/en-us/articles/intel-performance-tuning-utility/
Bon j'ai jamais teste les versions recentes, et encore moins la version linux.

Pour profiling memoire le *mieux* est de se le faire a la main. Avoir un bon memory systeme, qui gere tous les acces memoires (sauf peut etre ceux du early init, par exemple pour la CRT) et qui propose une analyze de leaks, c est vraiment bien important. Et plus facile que des outils qui vont 1/ tout ralentir et 2/ ne permettent souvent pas de savoir a partir de quand dans le programme on veut analyser les fuites. Bon apres c est mon avis, et perso je prefere aussi de loin utiliser mon profiler interne pour tout ce qui est profiling des appels de fonctions/etc (ie pas cache misses, load hit stores,...) que tous les outils/libs sur le marche, du moins pour une utilisation quotidienne.

Ca depend des cas kufa. Bien souvent valgridn/callgrind/cachegrind suffise a detecter les erreurs et a les corriger rapidement. Ce n'est qu'apres avoir passer au moins une heure avec ces outils la que je commence a rajouter du code dans l'application.

Ca depend beaucoup des applications que l'on considere egalement. Pour simuler la memoire valgrind a besoin de serialiser les differents threads qui pourrait tourner. Debugger/profiler une application multi-threader devient alors impossible/peu pertinent avec valgrind.

En passant, un lien sur la lib papi pour obtenir les compteurs de performance du systeme (pour linux, requiert un noyau special) http://icl.cs.utk.edu/papi/

godrik: oui, je suis d'accord, ca depends des cas. Le probleme c'est que valgridn/etc ne sont pas vraiment multi-platforme, alors que tu peux faire en sorte que ton systeme de memoire le soit. Apres c'est une question d'habitude et de ce qu'on veut obtenir, perso je fais tres attention a ma gestion de memoire, tant au niveaux leaks, que performance et fragmentation. Ces outils ne me permettent de maniere generale pas de faire des analyses suffisantes pour ca. Plus tu veux de controle et de possibilites d avoir des informations pertinentes (systems en questions, etc), plus il est utile de le faire soit meme. Et ce n'est pas si difficile de le faire une fois, puis de le porter/adapter a un autre projet. Bon, si on veut un GUI, plus boring deja =)