Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Optimisation de code
Bonjour,
Je travail sur différents projet (C, Java) et j'attache une grande importance à l'optimisation du code. J'entends par optimisation, la détection des fonctions qui prennent du temps durant l'exécution.
J'ai entendu parler de différents outils (petit pré-requis : je ne bosse que sous linux) permettant de détecter justement ces fonctions.
Excusez moi si je dis n'importe quoi, mais je me souvient vaguement d'un nom d'outil contenant "vgen" ?
Pouvez vous me conseillez svp
Merci à vous !
En fait j'ai entendu des gens parler d'outils permettant de déterminer quelle fonctions d'un programme prenait le plus de ressources et donc mettait le plus de temps à s'effectuer. Ces personnes utilisaient aussi le mot profiling
Je cherche ce type d'outils
Bien sûr, si je pouvais prendre contact avec ces personnes, je le ferai
ben gprof est sans doute l'outil que tu cherches
http://c.developpez.com/tutgcc/c1524.php
http://spe.univ-corse.fr/bernardiweb...vers/gprof.pdf
En java, si tu travailles sous Netbeans, il y a un profiler d'intégré et qui est vraiment bien (mémoire, temps passé dans les fonctions, nombre de threads, etc).
Je pense que cela existe sous Eclipse aussi.
Merci pour vos conseils
En plus de gprof:
oprofile sous linux, meilleur que gprof
valgrind sous linux (plusieurs profilers : heap, stack, call graph, etc... et même un traceur), a utiliser avec kcachegrind
sysprof sous linux
sous Windows (et linux, aussi), il y a vtunes (d'Intel)
en commercial, il y a purify
pour la gestion de la mémoire :
memprof (modifiée par rasterman). Tres utile pour savoir si, au cours tu temps, ton programme fragmente la mémoire ou pas (utilisation trop intensive de malloc / free).
enfin, gcov peut aussi te venir en aide pour savoir si des parties de codes sont souvent appelées, ou pas du tout, ce qui permet de savoir si par exemple une fonction est trop appelées, par rapport a ce que tu attends a priori.
pour ma part, si tu es sous linux, c'est oprofile + valgrind avec kcachegrind a utiliser en priorité. Les avantages sont que tu n'as pas besoin de recompiler ton prog, comme avec gprof. De plus, j'ai souvent lu que gprof ne donne pas de temps d'exécution très précis.
Juste une toute petite remarque : 90% du temps, les baisses de performances sont dues à une architecture (et donc une conception) douteuse. L'optimisation du code est de moins en moins en cause (les compilateurs faisaient un travail de plus en plus exemplaire).
Donc si tu es vraiment très prés de la performance de ton code, penses à faire une revue de conception AVANT l'optimisation (tweak) du code à proprement parler.
D'un autre côté, le profiling peut justement révéler ce genre de faiblesse, pourvu qu'on n'ait pas le nez dans le guidon. Mais j'approuve complètement : dans la plupart des applications actuelles, la micro-optimisation fait plus de mal que de bien.Envoyé par Garulfo
--
Jedaï
Oui en fait je ne voulais pas dire que le principe était mauvais (le profiling) mais que la solution vient souvent d'une restructuration de l'architecture. Merci de la précision.
Pour l'avoir pratiqué et avoir travaillé avec des personnes qui mettent en oeuvre, avec succès, ce genre de techniques depuis plusieurs dizaines d'années, je peux dire que le problème est plus compliqué que ça.
Certes, les compilateurs font de mieux en mieux leur travail depuis quelque temps, et c'est un bien indiscutable, mais le fait que les RAM des ordinateurs soient de plus en plus lentes, comparativement avec les processeurs, rend l'utilisation de la mémoire plus délicate qu'auparavant. Les temps d'accès aux données situées en dehors du cache du processeur, les fameux défauts de cache, coûtent chaque jour un peu plus. Certes, les caches évoluent et deviennent un peu plus gros à chaque nouvelle génération, ajoutent encore plus de niveaux, mais le problème reste sensiblement le même ; il s'agit du problème de localisation des structures de données.
Ce qui coûte cher aujourd'hui, c'est les défauts de cache, et, contrairement à il y a quelques années, il vaut mieux dans certains cas recalculer des valeurs intermédiaires plutôt que d'y accéder par l'intermédiaire d'une variable, même temporaire.
N'oublies pas que tu es dans un domaine spécifique et encadré de gens compétents d'un point de vue design.
En général, études à l'appuie, je t'assure que 90% du temps, dans l'industrie, les problèmes de performances sont des problèmes d'architecture. Ce qui veut dire qu'il reste un 10% du temps (et en fait c'est plus un domaine: le calcul de haute intensité) où c'est vraiment un problème de tweaking.
entierement d'accord
Uniquement dans des cas specifiques : Temps reell "Lourd" en donnees ou en calcul, algos d'essais successifs (bio-genetique), modeles numeriques lourds (modeles atmospheriques, de vagues, aerodynamiques)...
Dans ces cas-la, oui la plus petite amelioration de stockage, de boucle, d'algo d'adressage etc devient important...
Dans le reste des cas, c'est en general effectivement un probleme d'architecture, de conception, voire d'outils... (exemple : utiliser des langages dynamiques comme Java pour faire de l'affichage de milliers de vecteurs), que ce soit pour des raisons historiques, des raisons de muvais choix initiaux car mauvaise prise en compte des contraintes, ou des raisons d'architecture proprement dite (avoir pris une base de donnees Oracle pour gerer une BD a 3 clefs par exemple, ou bien avoir pousser un decoupage a l'extreme, generant des empilements invraisemblables d'appels de fonctions, ou bien une mauvaise analyse)
Répondre avec citation
Partager