gnome-devel-docs master - en to fr translation catalogue (87 entries)

note: (itstool) path: page/title
en: Disk Seeks Considered Harmful
fr: Effets dommageables des recherches sur disque

note: (itstool) path: page/p (itstool) path: section/p
en: Disk seeks are one of the most expensive operations you can possibly perform. You might not know this from looking at how many of them we perform, but trust me, they are. Consequently, please refrain from the following suboptimal behavior:
fr: La recherche sur disque est une des opérations les plus coûteuses que vous puissiez peut-être réaliser. Vous pouvez ne pas le savoir à partir de l’examen du décompte des recherches effectuées, mais croyez-moi, elles sont coûteuses. Par conséquent, abstenez-vous des piètres comportements ci-après :

note: (itstool) path: item/p
en: Placing lots of small files all over the disk.
fr: disperser nombre de petits fichiers un peu partout dans le disque,

note: (itstool) path: item/p
en: Opening, stating, and reading lots of files all over the disk
fr: ouvrir, inspecter et lire beaucoup de fichiers partout sur le disque.

note: (itstool) path: item/p
en: Doing the above on files that are laid out at different times, so as to ensure that they are fragmented and cause even more seeking.
fr: exécuter les opérations précédentes sur des fichiers montés à plusieurs reprises, comme pour s’assurer de leur fragmentation et provoquer des recherches encore plus coûteuses,

note: (itstool) path: item/p
en: Doing the above on files that are in different directories, so as to ensure that they are in different cylinder groups and cause even more seeking.
fr: exécuter les opérations précédentes sur des fichiers situés dans des répertoires différents, comme pour s’assurer qu’ils soient dans des groupes de pistes différents et provoquer des recherches encore plus coûteuses,

note: (itstool) path: item/p
en: Repeatedly doing the above when it only needs to be done once.
fr: faire les opérations précédentes plusieurs fois alors qu’on aurait pu se contenter d’une seule.

note: (itstool) path: page/p
en: Ways in which you can optimize your code to be seek-friendly:
fr: Voici des conseils pour optimiser votre code pour des recherches optimales :

note: (itstool) path: item/p
en: Consolidate data into a single file.
fr: rassemblez les données dans un seul fichier,

note: (itstool) path: item/p
en: Keep data together in the same directory.
fr: gardez l’ensemble des données dans un même répertoire,

note: (itstool) path: item/p
en: Cache data so as to not need to reread constantly.
fr: mettez en cache les données afin de ne pas avoir à les relire constamment,

note: (itstool) path: item/p
en: Share data so as not to have to reread it from disk when each application loads.
fr: partagez les données afin de ne pas avoir à les relire à partir du disque à chaque chargement de l’application,

note: (itstool) path: item/p
en: Consider caching all of the data in a single binary file that is properly aligned and can be mmaped.
fr: envisagez la mise en cache de toutes les données dans un fichier binaire unique, bien aligné et qui peut être mappé.

note: (itstool) path: page/p
en: The trouble with disk seeks are compounded for reads, which is unfortunately what we are doing. Remember, reads are generally synchronous while writes are asynchronous. This only compounds the problem, serializing each read, and contributing to program latency.
fr: Le problème de la recherche sur disque est aggravé dans le cas des lectures, qui est malheureusement ce que nous faisons. N’oubliez pas, les lectures s’effectuent en règle générale de manière synchrone tandis que les écritures s’effectuent de manière asynchrone. Ce seul fait complique le problème : sérialiser chaque lecture contribue à la latence du programme.

note: (itstool) path: license/p
en: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. You may obtain a copy of the GNU Free Documentation License from the Free Software Foundation by visiting <link href="http://www.fsf.org">their Web site</link> or by writing to: Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor Boston, MA 02110-1335, USA.
fr: Autorisation est accordée pour copier, distribuer et/ou modifier ce document selon les termes de la  GNU Free Documentation License, Version 1.1 ou ultérieure publiée par la Free Software Foundation sans section inaltérable, sans texte de première page de couverture ni texte de dernière page de couverture. Vous pouvez obtenir une copie de la  GNU Free Documentation License de la Free Software Foundation en suivant <link href="http://www.fsf.org">ce site Web</link> ou en écrivant à : Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor Boston, MA 02110-1335, USA.

note: (itstool) path: license/p
en: Many of the names used by companies to distinguish their products and services are claimed as trademarks. Where those names appear in any GNOME documentation, and those trademarks are made aware to the members of the GNOME Documentation Project, the names have been printed in caps or initial caps.
fr: La plupart des noms utilisés par les entreprises pour distinguer leurs produits et services sont des marques déposées. Lorsque ces noms apparaissent dans la documentation GNOME et que les membres du projet de Documentation GNOME sont informés de l’existence de ces marques déposées, soit ces noms entiers, soit leur première lettre est en majuscule.

note: (itstool) path: info/desc
en: Software can be optimized in many ways: for speed, program size, or memory use. This section contains guides and tutorials for optimizing your software.
fr: Un logiciel peut être optimisé de plusieurs façons : pour la vitesse, la taille du programme ou l’utilisation de la mémoire. Cette section contient conseils et tutoriels pour optimiser les logiciels.

note: (itstool) path: page/title
en: Optimization Guide
fr: Guide d’optimisation

note: (itstool) path: section/p
en: This is a brief introduction to optimization, both the hows and the whys. Details of individual tools and techniques are left for later articles, but a collection of hints and tricks is provided.
fr: Il s’agit d’une brève introduction à l’optimisation, à la fois le comment et le pourquoi. Le détail des outils et techniques individuels est reporté à des articles ultérieurs, mais une collection de trucs et astuces est fournie.

note: (itstool) path: section/p (itstool) path: page/p
en: This article describes how to use the <app>Massif</app> heap profiler with GNOME applications. We describe how to invoke, interpret, and act on the output of <app>Massif</app>. The <app>Swell Foop</app> game is used as an example.
fr: Cet article décrit comment utiliser le profileur de tas <app>Massif</app> avec les applications GNOME. Nous décrivons comment appeler, interpréter et agir sur la sortie de <app>Massif</app>. Le jeu <app>Swell Foop</app> est utilisé comme un exemple.

note: (itstool) path: section/title
en: Harmfulness
fr: Ce qui est nuisible

note: (itstool) path: page/title
en: What are we Optimizing?
fr: Qu’optimisons nous ?

note: (itstool) path: page/p
en: When we optimize for GNOME the first thing to remember is this: we are not trying to make the program better, we are trying to make the person using the computer happier.
fr: Quand nous optimisons pour GNOME, voici une première chose dont il faut se souvenir : nous ne tentons pas d’améliorer un programme, nous essayons de mieux satisfaire l’utilisateur.

note: (itstool) path: page/p
en: Better programs make people happier, but there are some improvements that will make them a lot happier than others: Responsiveness, start-up time, easy to access commands and not having the computer go into swap the moment more than two programs are open.
fr: Meilleur est le programme, plus les gens sont satisfaits, mais il est des améliorations qui les satisfont plus que d’autres : réactivité, temps de démarrage, facilité d’accès aux commandes et le fait de ne pas avoir l’ordinateur qui utilise la mémoire virtuelle dès que plus de deux programmes sont ouverts.

note: (itstool) path: page/p
en: Traditional optimization tackles concepts like CPU use, code size, the number of mouse clicks and the memory use of the program. This second list has been chosen to correlate with the first list, however there is an important difference: The person using GNOME doesn't care about the second list, but they care a lot about the first list. When optimizing GNOME programs we will reduce CPU use, memory use and all those things, but these are the means to the end, not the final goal. We are optimizing for people.
fr: Une optimisation traditionnelle s’attaque à des concepts comme l’utilisation de la CPU, la taille du code, le nombre de clics de souris et la mémoire utilisée par le programme. Cette deuxième énumération est corrélée avec celle de l’alinéa précédent, cependant il y a une différence importante : l’utilisateur de GNOME ne se soucie absolument pas des critères de cette deuxième énumération, mais beaucoup plus de ceux de la première. En optimisant les programmes GNOME, nous réduisons l’utilisation de la CPU, de la mémoire et beaucoup d’autres choses, mais ce sont des aboutissements et non des finalités. Nous optimisons pour les personnes.

note: (itstool) path: section/title
en: Doing the Optimization
fr: Réalisation d’une optimisation

note: (itstool) path: section/p
en: The previous section omitted one important qualifier: To optimize something it has to be measurable. You can't measure happiness. However, you can measure start-up time so you can tell if you have improved it. Happiness will then, hopefully, follow.
fr: Le paragraphe précédent a omis de citer un qualifiant important : on ne peut optimiser que ce qui est mesurable. La satisfaction n’est pas quantifiable. Mais, vous pouvez mesurer un temps de démarrage et dire si vous l’avez amélioré. Nous avons quelques espoirs qu’une satisfaction s’ensuive.

note: (itstool) path: section/p
en: Optimization is the process of measurement, refinement and re-measurement. So the first thing you must do is find a way to measure what you are optimizing. Ideally this measurement is a single number, for example: the time taken to perform a task. This is your benchmark, it is the only way to tell if you are winning or losing. There is a big difference between a program that <em>should</em> be fast and a program that <em>is</em> fast.
fr: L’optimisation est le processus de mesure, d’affinage et de mesure à nouveau. Donc la première chose que vous devez faire est de trouver un moyen de mesurer ce que vous optimisez. Idéalement, cette mesure est un nombre unique, par exemple : le temps nécessaire pour effectuer une tâche. C’est votre point de référence, c’est la seule façon de savoir si vous êtes gagnant ou perdant. Il y a une grande différence entre un programme qui <em>devrait</em> être rapide et un programme qui <em>est</em> rapide.

note: (itstool) path: section/p
en: Once you have a basic benchmark you need to find out why your code is not doing as well as it should. It is tempting to do this by inspection: just looking at the code and trying to spot something that looks like it needs improvement. You will invariably be wrong. Using a profiler to get a detailed break-down of what your program really does is the only way to be sure.
fr: Une fois que vous avez un point de référence, il faut savoir pourquoi le code ne fonctionne pas aussi bien qu’il le devrait. Il est tentant de le faire par inspection : en regardant simplement le code pour essayer de repérer quelque chose d’améliorable. Vous serez invariablement dans l’erreur. La seule façon d’être sûr est d’utiliser un profileur pour obtenir la décomposition détaillée de ce que votre programme fait réellement.

note: (itstool) path: section/p
en: Usually the problem is isolated to small sections of code. Pick the worst place and concentrate on that first. Once that is done, rerun the profiler and repeat. As you proceed the gains made at each step will get less and less, at some point you will have to decide that the results are good enough. If your efforts are only extracting 10% improvements then you are well past the point where you should have stopped.
fr: Habituellement, vous cernez les problèmes dans de petites portions de code. Repérez la pire et centrez votre attention d’abord sur elle. Quand vous avez terminé, relancez le profileur et recommencez. À mesure que vous avancez, les progrès réalisés à chaque étape sont de plus en plus faibles, jusqu’au moment où vous aurez à décider si les résultats sont assez bons. Si vos efforts aboutissent à ne serait-ce que 10 % d’améliorations, alors vous êtes bien au delà du point où vous auriez pu vous arrêter.

note: (itstool) path: section/p
en: Don't forget the big picture. For example, rather than just trying to speed up a piece of code, ask yourself if it needs to be run at all. Could it be combined with another piece of code? Can the results of previous calculations be saved and reused? It won't even need to be optimized if it is in a place where the user is never going to notice it. Worse still, the code may already be optimized and is doing the heavy calculations now to avoid doing them later. Code does not run in isolation and neither does the optimization process.
fr: Ayez une vue d’ensemble. Par exemple, plutôt que d’essayer de rendre plus rapide un morceau du code, demandez-vous plutôt s’il doit être exécuté. Peut-il être combiné avec une autre partie de code ? Les résultats de calculs antérieurs peuvent-ils être sauvegardés et réutilisés ? Ce code a-t-il même besoin d’être optimisé, s’il est à un endroit où l’utilisateur ne va jamais le parcourir ? Pire encore, le code peut déjà avoir été optimisé et effectuer maintenant des calculs lourds pour éviter d’avoir à les faire plus tard. Un morceau de code ne s’exécute pas isolément, pas plus que le processus d’optimisation.

note: (itstool) path: section/title
en: Hints
fr: Conseils pratiques

note: (itstool) path: item/title
en: The Fundamentals
fr: Les Fondamentaux

note: (itstool) path: item/p
en: Re-run your benchmark after every change you make to the code and keep a log of everything you change and how it affects the benchmark. This lets you undo mistakes and also helps you not to repeat mistakes.
fr: Relancez le test de performance après chaque changement apporté au code ; gardez un journal de toutes les modifications en notant la manière dont elles affectent le test de performance. Procéder ainsi vous permet d’annuler les erreurs et vous aide à ne pas les répéter.

note: (itstool) path: item/p
en: Make sure your code is correct and bug-free before optimizing it. Check that it remains correct and bug-free after optimization.
fr: Assurez-vous que le code est correct et ne contient pas de bogues avant de l’optimiser. Vérifiez qu’il est toujours correct et sans bogues après optimisation.

note: (itstool) path: item/p
en: Optimize at the high level before optimizing the details.
fr: Optimisez au général avant d’optimiser les détails.

note: (itstool) path: item/p
en: Use the right algorithm. The classic text-book example is using quick-sort instead of bubble-sort. There are many others, some save memory, some save CPU. Also, see what shortcuts you can make: you can do quicker than quick-sort if you are prepared to make some compromises.
fr: Utilisez le bon algorithme. L’exemple classique des ouvrages est de conseiller l’utilisation d’un tri rapide plutôt qu’un tri à bulle. Il en existe beaucoup d’autres, certains économisent la mémoire, d’autres la CPU. Également, voyez quels sont les raccourcis possibles : vous pouvez faire plus rapide que le tri rapide si vous êtes prêt à quelques compromis.

note: (itstool) path: item/p
en: Optimization is a trade-off. Caching results speeds up calculations, but increases memory use. Saving data to disk saves memory, but costs time when it is loaded back from disk.
fr: L’optimisation est un arbitrage. Mettre en cache des résultats accélère les calculs, mais augmente l’utilisation de la mémoire. Enregistrer les données sur disque économise la mémoire, mais prend plus de temps quand il faut les rappeler.

note: (itstool) path: item/p
en: Make sure you choose a wide variety of inputs to optimize against. If you don't it is easy to end up with a piece of code carefully optimized for one file and no others.
fr: Mettez en concurrence les optimisations sur un large éventail d’entrées. À défaut, il est courant de se retrouver avec une portion de code soigneusement optimisée pour un fichier donné et pas les autres.

note: (itstool) path: item/p
en: Avoid expensive operations: Multiple small disk reads. Using up lots of memory so disk swapping becomes necessary. Avoid anything that writes or reads from the hard disk unnecessarily. The network is slow too. Also avoid graphics operations that need a response from the X server.
fr: Évitez des opérations coûteuses : la multiplication de petites lectures sur les disques, l’utilisation de grosses quantités de mémoire qui nécessitent l’emploi de la mémoire virtuelle, les écritures ou lectures inutiles sur disque dur. Le réseau est également lent. Évitez aussi les opérations graphiques qui ont besoin d’une réponse du serveur X.

note: (itstool) path: item/title
en: Traps for the Unwary
fr: Pièges pour imprudents

note: (itstool) path: item/p
en: Beware of side effects. There can often be strange interactions between different sections of code, a speed-up in one part can slow another part down.
fr: Méfiez-vous des effets collatéraux. Il y a souvent d’étranges interactions entre diverses parties du code, l’accélération d’une partie peut ralentir l’autre.

note: (itstool) path: item/p
en: When timing code, even on a quiet system, events outside the program add noise to the timing results. Average over multiple runs. If the code is very short, timer resolution is also a problem. In this case measure the time the computer takes to run the code 100 or 1000 times. If the times you are recording are longer than a few seconds, you should be OK.
fr: Pendant le chronométrage du temps, même sur un système peu chargé, les événements en dehors du programme ajoutent du bruit au résultat. Moyennez-les sur plusieurs exécutions. Si le code est très court, la résolution du chronomètre peut devenir aussi un problème. Dans ce cas, mesurez le temps que l’ordinateur met pour exécuter le code 100 ou 1000 fois. Si le temps que vous enregistrez est plus long que quelques secondes, cela devrait être correct.

note: (itstool) path: item/p
en: It is very easy to be misled by the profiler. There are stories of people optimizing the operating system idle-loop because that is where it spent all its time! Don't optimize code that does nothing the user cares about.
fr: Il est très facile d’être induit en erreur par le profileur. On raconte des histoires de personnes optimisant la boucle d’attente du système d’exploitation parce que c’est là que l’ordinateur passait tout son temps ! N’optimisez pas le code des choses dont l’utilisateur n’a rien à faire.

note: (itstool) path: item/p
en: Remember the resources on the X server. Your program's memory usage doesn't include the pixmaps that are stored in the X server's process, but they are still using up memory. Use xrestop to see what resources your program is using.
fr: N’oubliez pas les ressources sur le serveur X. Le décompte de la mémoire utilisée par votre programme ne comprend pas les images <literal>pixmap</literal> stockées par les processus du serveur X, mais ces images dépensent encore de la mémoire. Utilisez <application>xrestop</application> pour prendre connaissance des ressources utilisées par votre programme.

note: (itstool) path: item/title
en: Low Level Hints
fr: Conseils niveau système

note: (itstool) path: item/p
en: When optimizing memory use, be wary of the difference between peak usage and average memory usage. Some memory is almost always allocated, this is usually bad. Some is only briefly allocated, this may be quite acceptable. Tools like massif use the concept of space-time, the product of memory used and the duration it was allocated for, instead.
fr: Quand vous optimisez l’utilisation de la mémoire, faites la différence entre usage de crête et usage moyen. Que de la mémoire soit allouée de manière pratiquement permanente est en règle générale mauvais. Que de la mémoire soit allouée sur de brèves périodes est tout à fait acceptable . Des outils comme <application>massif</application> utilisent plutôt le concept espace*temps, produit de la mémoire utilisée multiplié par la durée de son allocation.

note: (itstool) path: item/p
en: Time simplified bits of code that do only the things you know are essential, this gives an absolute lower limit on the time your code will take. For example, when optimizing a loop time the empty loop. If that is still too long no amount of micro-optimization will help and you will have to change your design. Make sure the compiler doesn't optimize away your empty loop.
fr: Chronométrez des portions de code simplifiées qui n’exécutent que les choses que vous savez être essentielles ; vous obtiendrez ainsi une limite inférieure absolue du temps que votre code prendra. Par exemple, pour optimiser une boucle, chronométrez la boucle d’attente. Si elle est encore trop longue, les micro-optimisations, aussi nombreuses soient-elles, ne vous seront d’aucun secours : vous devez modifier votre conception. Assurez-vous que le compilateur n’a pas optimisé par ailleurs votre boucle d’attente.

note: (itstool) path: item/p
en: Move code out from inside loops. A slightly more complicated piece of code that is executed once is far quicker than a simple piece of code executed a thousand times. Avoid calling slow code often.
fr: Déplacez le code en dehors des boucles. Une portion de code légèrement plus complexe exécutée une seule fois est beaucoup plus rapide qu’une portion de code simple exécutée une centaine de fois. Évitez d’appeler trop souvent du code lent.

note: (itstool) path: item/p
en: Give the compiler as many hints as possible. Use the const keyword. Use <code>G_INLINE_FUNC</code> for short, frequently called, functions. Look up <code>G_GNUC_PURE</code>, <code>G_LIKELY</code> and the other glib miscellaneous macros. Use the macros instead of gcc-specific keywords to ensure portability.
fr: Utilisez toutes les astuces possibles avec le compilateur. Servez-vous du mot-clé <literal>const</literal>, et de <envar>G_INLINE_FUNC</envar> pour les fonctions courtes fréquemment appelées. Envisagez l’utilisation de <envar>G_GNUC_PURE</envar>, <envar>G_LIKELY</envar> et d’autres macros de <literal>glib</literal>. Utilisez les macros au lieu des mots-clés spécifiques à <application>gcc</application> pour assurer la portabilité.

note: (itstool) path: item/p
en: Don't use assembly language. It is not portable and, while it may be fast on one processor, it is not even guaranteed to be fast on every processor that supports that architecture (e.g. Athlon vs. Pentium 4).
fr: N’utilisez pas le langage assembleur. Il n’est pas portable et, quand il est plus rapide sur un processeur, ce n’est pas garanti qu’il le soit sur tous les processeurs qui supportent cette architecture (par ex. Athlon versus Pentium 4).

note: (itstool) path: item/p
en: Don't rewrite an existing library routine unless you are sure it is unnecessarily slow. Many CPU-intensive library routines have already been optimized. Conversely, some library routines are slow, especially ones that make system calls to the operating system.
fr: Ne réécrivez pas une routine existante de bibliothèque, à moins d’être sûr qu’elle est inutilement lente. Beaucoup de routines de bibliothèques utilisant intensivement la CPU ont déjà été optimisées. Inversement, certaines routines de bibliothèque sont lentes, en particulier celles faisant appel au système d’exploitation.

note: (itstool) path: item/p
en: Minimize the number of libraries you link to. The fewer libraries to link in, the faster the program starts. This is a difficult thing to do with GNOME.
fr: Minimisez le nombre de bibliothèques auxquelles vous liez votre code. Moins il y a de bibliothèques à lier, plus le programme se lancera rapidement. Ce n’est pas facile à faire avec GNOME.

note: (itstool) path: item/title
en: High Level Tricks
fr: Astuces niveau abstractions

note: (itstool) path: item/p
en: Take advantage of concurrency. This doesn't just mean using multiple processors, it also means taking advantage of the time the user spends thinking about what they are going to do next to perform some calculations in anticipation. Do calculations while waiting for data to be loaded off disk. Take advantage of multiple resources, use them all at once.
fr: Utilisez la concomitance. Ce conseil ne vise pas uniquement la simultanéité des processus multiples, mais le fait qu’il faut mettre à profit le temps que l’utilisateur passe à réfléchir à ses actions futures pour anticiper quelques calculs. Faites des opérations en attendant le chargement des données disque. Exploitez la multiplicité des ressources, utilisez-les toutes ensemble.

note: (itstool) path: item/p
en: Cheat. The user only has to think that the computer is fast, it doesn't matter whether it actually is or not. It is the time between the command and the answer that is important, it doesn't matter if the response is pre-calculated, cached, or will in fact be worked out later at a more convenient time, as long as the user gets what they expect.
fr: Trichez. L’utilisateur doit imaginer un ordinateur rapide, aucune importance qu’il le soit effectivement ou non. L’important est le délai entre commande et réponse ; peu importe que la réponse soit calculée par avance, en cache ou mise au point plus tard à un moment plus opportun pourvu que l’utilisateur obtienne ce qu’il attend.

note: (itstool) path: item/p
en: Do things in the idle loop. It is easier to program than using full multi-threading but still gets things done out of the users eye. Be careful though, if you spend too long in the idle loop your program will become sluggish. So regularly give control back to the main loop.
fr: Faites quelque chose pendant la boucle d’attente. C’est plus facile à programmer qu’une pleine utilisation de processus multiples, mais faites toujours faire les choses hors de la vue de l’utilisateur. Attention cependant, si vous passez trop de temps dans la boucle d’attente, votre programme deviendra mollasson. Donc, redonnez régulièrement le contrôle à la boucle principale.

note: (itstool) path: item/p
en: If all else fails, tell the user that the code is going to be slow and put up a progress bar. They won't be as happy as if you had just presented the results, but they will at least know the program hasn't crashed and they can go get a cup of coffee.
fr: Si tout ce qui précède échoue, avouez à l’utilisateur que le code est lent et programmez une barre de progression. Il ne sera pas aussi satisfait que par la présentation des résultats, mais il saura au moins que le programme ne s’est pas arrêté brutalement et qu’il peut aller chercher une tasse de café.

note: (itstool) path: page/title
en: Using <app>Massif</app> for Profiling Memory Use in GNOME Software
fr: Utilisation de <app>Massif</app> pour profiler l’utilisation de la mémoire des logiciels GNOME.

note: (itstool) path: section/p
en: <app>Massif</app> is a member of the <link href="http://valgrind.org/">valgrind</link> suite of memory-profiling tools. Its purpose is to give a detailed view of dynamic memory usage during the lifetime of the program. Specifically it records the memory use of the heap and the stack.
fr: <app>Massif</app> fait partie de la suite d’outils de profilage mémoire <link href="http://valgrind.org/">valgrind</link>. Son but est de donner une vue détaillée de l’utilisation de mémoire dynamique pendant la durée du programme. Plus précisément, il enregistre l’utilisation de la mémoire du tas et de la pile.

note: (itstool) path: section/p
en: The heap is the region of memory which is allocated with functions like malloc. It grows on demand and is usually the largest region of memory in a program. The stack is where all the local data for functions is stored. This includes the "automatic" variables in C and the return address for subroutines. The stack is typically a lot smaller and a lot more active than the heap. We won't consider the stack explicitly since <app>Massif</app> treats it as though it were just another part of the heap. <app>Massif</app> also gives information about how much memory is used to manage the heap.
fr: Le tas est une zone mémoire dans laquelle des fonctions comme <function>malloc</function> font leurs allocations. Le tas augmente à la demande et est généralement la plus grande zone mémoire d’un programme. La pile est l’endroit où toutes les données locales des fonctions sont stockées, y compris les variables « automatiques » du C et l’adresse de retour des sous-programmes. La pile est habituellement beaucoup plus petite et beaucoup plus active que le tas. Nous ne la prendrons pas explicitement en considération puisque <application>Massif</application> traite la pile comme faisant partie du tas. <application>Massif</application> fournit également des informations sur les quantités de mémoire utilisées pour la gestion du tas.

note: (itstool) path: section/p
en: <app>Massif</app> produces two output files: a graphical overview in a postscript file and a detailed breakdown in a text file.
fr: <app>Massif</app> produit deux fichiers de sortie : un aperçu graphique dans un fichier postscript et une analyse détaillée dans un fichier texte.

note: (itstool) path: section/title
en: Using <app>Massif</app> with GNOME
fr: Utilisation de <app>Massif</app> avec GNOME

note: (itstool) path: section/p
en: <app>Massif</app> has very few options and for many programs does not need them. However for GNOME applications, where memory allocation might be buried deep in either glib or GTK, the number of levels down the call-stack Massif descends needs to be increased. This is achieved using the --depth parameter. By default this is 3; increasing it to 5 will guarantee the call-stack reaches down to your code. One or two more levels may also be desirable to provide your code with some context. Since the level of detail becomes quickly overwhelming it is best to start with the smaller depth parameter and only increase it when it becomes apparent that it isn't sufficient.
fr: <app>Massif</app> possède très peu d’options et de nombreux programmes n’en ont pas besoin. Toutefois, pour les applications GNOME, où l’allocation de mémoire pourrait être profondément enfouies dans glib ou GTK, le nombre de niveaux de la pile des appels où Massif descend doit être augmenté. Ce résultat est obtenu en utilisant le paramètre --depth. Par défaut c’est 3 ; l’augmenter à 5 garantira que la pile d’appel descend jusqu’à votre code. Un ou deux autres niveaux peuvent également être souhaitable pour fournir à votre code un certain contexte. Puisque le niveau de détail devient rapidement excessif, il est préférable de commencer avec un paramètre de profondeur faible et de ne l’augmenter que lorsqu’il devient évident qu’il n’est pas suffisant.

note: (itstool) path: section/p
en: It is also useful to tell <app>Massif</app> which functions allocate memory in glib. It removes an unnecessary layer of function calls from the reports and gives you a clearer idea of what code is allocating memory. The allocating functions in glib are g_malloc, g_malloc0, g_realloc, g_try_malloc, and g_mem_chunk_alloc. You use the --alloc-fn option to tell Massif about them.
fr: Il est également utile d’indiquer à <application>Massif</application> quelles fonctions allouent de la mémoire dans <literal>glib</literal>. Cette indication supprime une couche superflue d’appels de fonctions dans les rapports et permet d’avoir une idée plus claire sur les parties de code qui allouent de la mémoire. Les fonctions d’allocation dans <literal>glib</literal> sont : <function>g_malloc</function>, <function>g_malloc0</function>, <function>g_realloc</function>, <function>g_try_malloc</function> et <function>g_mem_chunk_alloc</function>. Utilisez l’option <option>--alloc-fn</option> pour les indiquer à <application>Massif</application>.

note: (itstool) path: section/p
en: Your command-line should therefore look something like:
fr: Votre ligne de commande devrait par conséquent ressembler à quelque chose comme :

note: (itstool) path: section/p
en: <app>Swell Foop</app> is the program we will be using as an example. Be warned that, since valgrind emulates the CPU, it will run <em>very</em> slowly. You will also need a lot of memory.
fr: <app>Swell Foop</app> est le programme que nous allons utiliser comme exemple. Sachez que, puisque valgrind émule la CPU, il fonctionne <em>très</em> lentement. Vous aurez aussi besoin de beaucoup de mémoire.

note: (itstool) path: section/title
en: Interpreting the Results
fr: Interprétation des résultats

note: (itstool) path: section/p
en: The graphical output of <app>Massif</app> is largely self explanatory. Each band represents the memory allocated by one function over time. Once you identify which bands are using the most memory, usually the big thick ones at the top you will have to consult the text file for the details.
fr: La sortie graphique de <app>Massif</app> est tout à fait explicite. Chaque bande représente la mémoire allouée par une fonction au fil du temps. Après avoir identifié les bandes qui utilisent le plus de mémoire, généralement les plus épaisses en haut, vous devez consulter le fichier texte pour les détails.

note: (itstool) path: section/p
en: The text file is arranged as a hierarchy of sections, at the top is a list of the worst memory users arranged in order of decreasing spacetime. Below this are further sections, each breaking the results down into finer detail as you proceed down the call-stack. To illustrate this we will use the output of the command above.
fr: Le fichier texte est constitué de paragraphes hiérarchisés, avec en tête de liste les utilisateurs de mémoire les plus gourmands rangés en ordre décroissant d’espace*temps. Au-dessous se trouvent d’autres paragraphes ; chacun analyse les résultats de plus en plus finement au fur et à mesure que vous vous enfoncez dans les profondeurs de la pile des appels de fonctions. Pour illustrer cela, nous utiliserons la sortie de la commande précédente.

note: (itstool) path: figure/title
en: <app>Massif</app> output for the unoptimized version of the <app>Swell Foop</app> program.
fr: Sortie de <app>Massif</app> pour la version non optimisée du programme <app>Swell Foop</app>.

note: (itstool) path: section/p
en: The image above shows a typical postscript output from <app>Massif</app>. This is the result you would get from playing a single game of <app>Swell Foop</app> (version 2.8.0) and then quitting. The postscript file will have a name like <file>massif.12345.ps</file> and the text file will be called <file>massif.12345.txt</file>. The number in the middle is the process ID of the program that was examined. If you actually try this example you will find two versions of each file, with slightly different numbers, this is because <app>Swell Foop</app> starts a second process and <app>Massif</app> follows that too. We will ignore this second process, it consumes very little memory.
fr: L’image ci-dessus montre une sortie postscript typique de <app>Massif</app>. C’est le résultat que vous obtiendriez en jouant une partie à un joueur de <app>Swell Foop</app> (version 2.8.0), et en quittant. Le fichier postscript aura un nom comme <file>massif.12345.ps</file> et le fichier texte sera appelé <file>massif.12345.txt</file>. Le nombre du milieu est l’identifiant (ID) du processus correspondant au programme examiné. Si vous testez réellement cet exemple, vous obtiendrez deux versions de chaque fichier, avec des nombres légèrement différents. C’est parce que <app>Swell Foop</app> lance un deuxième processus que <app>Massif</app> analyse également. Nous allons ignorer ce deuxième processus, car il consomme très peu de mémoire.

note: (itstool) path: section/p
en: At the top of the graph we see a large yellow band labelled gdk_pixbuf_new. This seems like an ideal candidate for optimization, but we will need to use the text file to find out what is calling gdk_pixbuf_new. The top of the text file will look something like this:
fr: En haut du graphique, est affichée une grande bande jaune étiquetée <literal>gdk_pixbuf_new</literal>. Elle semble être la candidate idéale pour une optimisation, mais nous avons besoin d’utiliser le fichier texte pour savoir qui appelle <literal>gdk_pixbuf_new</literal>. En tête du fichier texte, il y a quelque chose comme :

note: (itstool) path: section/p
en: The line with the '=' signs indicates how far down the stack trace we are, in this case we are at the top. After this it lists the heaviest users of memory in order of decreasing spacetime. Spacetime is the product of the amount of memory used and how long it was used for. It corresponds to the area of the bands in the graph. This part of the file tells us what we already know: most of the spacetime is dedicated to gdk_pixbuf_new. To find out what called gdk_pixbuf_new we need to search further down the text file:
fr: Le numéro dans la ligne avec les signes « = » indique la profondeur d’imbrication dans la pile des appels de fonctions où nous nous trouvons ; dans notre cas, nous sommes au sommet. Suit la liste des utilisateurs d’espace*temps mémoire du plus gourmand au moins gourmand. L’espace*temps mémoire représente la quantité de mémoire occupée multipliée par le temps d’utilisation. Il correspond à la surface des bandes sur le graphe. Cette première partie du fichier texte confirme ce que nous savions déjà : le gros de l’espace*temps est occupé par <literal>gdk_pixbuf_new</literal>. Pour savoir qui appelle <literal>gdk_pixbuf_new</literal>, il est nécessaire de rechercher plus bas dans le fichier texte :

note: (itstool) path: section/p
en: The first line tells us we are now four levels deep into the stack. Below it is a listing of the function calls that leads from here to gdk_pixbuf_new. Finally there is a list of functions that are at the next level down and call these functions. There are, of course, also entries for levels 1, 2, and 3, but this is the first level to reach right down through the GDK code to the <app>Swell Foop</app> code. From this listing, we can see instantly that the problem code is load_scenario.
fr: La première ligne indique que nous nous trouvons au quatrième niveau dans la profondeur de pile. Au-dessous, suit une liste des appels de fonctions menant de ce point à gdk_pixbuf_new. Enfin, vient une liste des fonctions situées au niveau immédiatement inférieur appelant ces fonctions. Bien entendu, les entrées pour les niveaux 1, 2 et 3 existent, mais le 4 est le premier niveau qui arrive directement jusqu’au code GDK de <application>Swell Foop</application>. À partir de cette liste, nous voyons instantanément que le problème se situe au niveau du code de <function>load_scenario</function>.

note: (itstool) path: section/p
en: Now that we know what part of our code is using all the spacetime we can look at it and find out why. It turns out that the load_scenario is loading a pixbuf from file and then never freeing that memory. Having identified the problem code, we can start to fix it.
fr: Maintenant que nous connaissons la partie du code qui utilise tout l’espace*temps mémoire, nous pouvons l’examiner et rechercher pourquoi. Il s’avère que <literal>load_scenario</literal> charge une image <literal>pixbuf</literal> à partir d’un fichier, puis ne libère jamais cette mémoire. Ayant identifié le code à problème, nous pouvons corriger.

note: (itstool) path: section/title
en: Acting on the Results
fr: Modification des résultats

note: (itstool) path: section/p
en: Reducing spacetime consumption is good, but there are two ways of reducing it and they are not equal. You can either reduce the amount of memory allocated, or reduce the amount of time it is allocated for. Consider for a moment a model system with only two processes running. Both processes use up almost all the physical RAM and if they overlap at all then the system will swap and everything will slow down. Obviously if we reduce the memory usage of each process by a factor of two then they can peacefully coexist without the need for swapping. If instead we reduce the time the memory is allocated by a factor of two then the two programs can coexist, but only as long as their periods of high memory use don't overlap. So it is better to reduce the amount of memory allocated.
fr: Réduire la consommation d’espace*temps mémoire est une bonne chose, mais il y a deux façons de faire et elles ne sont pas égales. Vous pouvez, soit réduire la quantité de mémoire allouée, soit réduire la durée d’allocation. Considérons un instant un système théorique avec uniquement deux processus en cours. Ces deux processus utilisent tous deux pratiquement la totalité de la mémoire RAM physique ; s’ils se superposent pleinement, alors le système va utiliser la partition de mémoire virtuelle et tout va ralentir. Il est évident que, si nous divisons par deux la quantité de mémoire utilisée par chaque processus, ils peuvent paisiblement coexister sans avoir besoin de l’utiliser. Si, au lieu de cela, nous divisons par deux les durées d’allocation mémoire, les deux programmes peuvent coexister, toujours sans virtualiser la mémoire, mais uniquement tant que leurs périodes d’utilisation de la mémoire haute ne se chevauchent pas. Réduire la quantité de mémoire allouée est donc préférable.

note: (itstool) path: section/p
en: Unfortunately, the choice of optimization is also constrained by the needs of the program. The size of the pixbuf data in <app>Swell Foop</app> is determined by the size of the game's graphics and cannot be easily reduced. However, the amount of time it spends loaded into memory can be drastically reduced. The image below shows the <app>Massif</app> analysis of <app>Swell Foop</app> after being altered to dispose of the pixbufs once the images have been loaded into the X server.
fr: Hélas, les choix d’une optimisation sont également contraints par les besoins du programme. La taille des données de pixbuf de <app>Swell Foop</app> est déterminée par la taille des graphiques du jeu et ne peut pas être facilement réduite. Toutefois, la durée de chargement de l’image pixbuf en mémoire peut être réduite de manière drastique. L’image ci-dessus affiche l’analyse par <app>Massif</app> de l’application <app>Swell Foop</app> modifiée pour se débarrasser du <literal>pixbuf</literal> une fois que les images ont été chargées dans le serveur X.

note: (itstool) path: figure/title
en: <app>Massif</app> output for the optimized <app>Swell Foop</app> program.
fr: Sortie de <app>Massif</app> pour la version optimisée du programme <app>Swell Foop</app>.

note: (itstool) path: section/p
en: The spacetime use of gdk_pixbuf_new is now a thin band that only spikes briefly (it is now the sixteenth band down and shaded magenta). As a bonus, the peak memory use has dropped by 200 kB since the spike occurs before other memory is allocated. If two processes like this were run together the chances of the peak memory usage coinciding, and hence the risk of swapping, would be quite low.
fr: L’espace*temps utilisé par <literal>gdk_pixbuf_new</literal> n’est maintenant plus qu’une fine bande qui pointe brièvement (c’est maintenant la seizième bande à partir du haut colorée en magenta). En prime, le pic de mémoire s’est affaissé de 200 Ko étant donné que la pointe de demande intervient avant les autres allocations mémoire. Si deux processus tels que celui-ci étaient lancés simultanément, les chances pour les pics d’utilisation mémoire coïncident, et en conséquence, les risques d’utilisation de la mémoire virtuelle, seraient très faibles.

note: (itstool) path: section/p
en: Can we do better ? A quick examination of <app>Massif</app>'s text output reveals: g_strdup to be the new major offender.
fr: Pouvons-nous faire mieux ? Un examen rapide du texte de sortie de <app>Massif</app> révèle que g_strdup serait maintenant le nouveau coupable.

note: (itstool) path: section/p
en: If we look closer though we see that it is called from many, many, places.
fr: Si nous regardons de plus près, nous voyons qu’il est appelé en de très, très nombreux endroits.

note: (itstool) path: section/p
en: We now face diminishing returns for our optimization efforts. The graph hints at another possible approach: Both the "other" and "heap admin" bands are quite large. This tells us that there are a lot of small allocations being made from a variety of places. Eliminating these will be difficult, but if they can be grouped then the individual allocations can be larger and the "heap admin" overhead can be reduced.
fr: Nous voilà maintenant confrontés à la diminution du rendement de nos efforts d’optimisation. Le graphique suggère une autre approche possible : les deux bandes <literal>other</literal> et <literal>heap admin</literal> sont relativement importantes. C’est la marque d’une multitude de petites allocations réalisées à divers endroits. Les éliminer est difficile, mais s’il est possible de les regrouper, les allocations unitaires seront plus grandes et le temps système du <literal>heap admin</literal> en sera réduit.

note: (itstool) path: section/title
en: Caveats
fr: Avertissements

note: (itstool) path: section/p
en: There are a couple of things to watch out for: Firstly, spacetime is only reported as a percentage, you have to compare it to the overall size of the program to decide if the amount of memory is worth pursuing. The graph, with its kilobyte vertical axis, is good for this.
fr: Il faut faire attention à deux choses : d’une part, la quantité espace*temps est uniquement restituée en pourcentage ; il faut la rapporter à la taille globale du programme pour décider si la quantité de mémoire mérite une optimisation. L’axe vertical du graphique, gradué en kilo-octets, vous aidera à prendre cette décision.

note: (itstool) path: section/p
en: Secondly, <app>Massif</app> only takes into account the memory used by your own program. Resources like pixmaps are stored in the X server and aren't considered by <app>Massif</app>. In the <app>Swell Foop</app> example we have actually only moved the memory consumption from client-side pixbufs to server-side pixmaps. Even though we cheated there are performance gains. Keeping the image data in the X server makes the graphics routines quicker and removes a lot of inter-process communication. Also, the pixmaps will be stored in a native graphics format which is often more compact than the 32-bit RGBA format used by gdk_pixbuf. To measure the effect of pixmaps, and other X resources use the <link href="http://www.freedesktop.org/Software/xrestop">xrestop</link> program.
fr: D’autre part, <app>Massif</app> ne prend en compte que la mémoire utilisée par votre programme. Des ressources telles que les images sont stockées dans le serveur X et ne sont pas prise en considération par <app>Massif</app>. Dans l’exemple <app>Swell Foop</app>, nous n’avons fait que déplacer la consommation de mémoire des images pixbufs côté client vers les images pixmaps côté serveur. Même si nous avons triché, nous obtenons des gains de performance. Garder les données d’image dans le serveur X rend les routines graphiques rapides et supprime beaucoup de communications entre les processus. En outre, les pixmaps seront stockées dans un format graphique natif qui est souvent plus compact que le format RGBA 32 bits utilisé par gdk_pixbuf. Pour mesurer l’incidence de pixmaps et autres ressources X, utilisez le programme <link href="http://www.freedesktop.org/Software/xrestop">xrestop</link>.
