<?xml version="1.0" ?>
<!DOCTYPE book PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd" [
  <!ENTITY kcachegrind '<application
>KCachegrind</application
>'>
  <!ENTITY cachegrind "<application
>Cachegrind</application
>">
  <!ENTITY calltree "<application
>Calltree</application
>">
  <!ENTITY callgrind "<application
>Callgrind</application
>">
  <!ENTITY valgrind "<application
>Valgrind</application
>">
  <!ENTITY oprofile "<application
>OProfile</application
>">
  <!ENTITY EBS "<acronym
>EBS</acronym
>">
  <!ENTITY TBS "<acronym
>TBS</acronym
>">
  <!ENTITY kappname "&kcachegrind;">
  <!ENTITY package "kdesdk">
  <!ENTITY % addindex "IGNORE">
  <!ENTITY % French "INCLUDE">
]>

<book lang="&language;">

<bookinfo>
<title
>Manuel de &kcachegrind;</title>

<authorgroup>
<author
><firstname
>Josef</firstname
> <surname
>Weidendorfer</surname
> <affiliation
> <address
><email
>Josef.Weidendorfer@gmx.de</email
></address>
</affiliation>
<contrib
>Auteur initial de la doculentation</contrib>
</author>

<author
><firstname
>Federico</firstname
> <surname
>Zenith</surname
> <affiliation
> <address
><email
>federico.zenith@member.fsf.org</email
></address>
</affiliation>
<contrib
>Mises à jour et corrections</contrib>
</author>

&traducteurYannVerley; &traducteurLudovicGrossard; &traducteurDamienRaudeMorvan; &traducteurJosephRichard; 

</authorgroup>

<copyright>
<year
>2002-2004</year>
<holder
>&Josef.Weidendorfer;</holder
>	
</copyright>
<copyright>
<year
>2009</year>
<holder
>Federico Zenith</holder>
</copyright>
<legalnotice
>&FDLNotice;</legalnotice>

<date
>2009-10-07</date>
<releaseinfo
>0.5.1</releaseinfo>

<abstract>
<para
>&kcachegrind; est un outil d'affichage de données de profilage écrit pour l'environnement &kde;. </para>
</abstract>

<keywordset>
<keyword
>KDE</keyword>
<keyword
>kdesdk</keyword>
<keyword
>Cachegrind</keyword>
<keyword
>Callgrind</keyword>
<keyword
>Valgrind</keyword>
<keyword
>Profilage</keyword>
</keywordset>

</bookinfo>


<chapter id="introduction">
<title
>Introduction</title>

<para
>&kappname; est un navigateur pour les données produites par des outils de profilage. Ce chapitre explique à quoi sert le profilage, comment cela fonctionne, et donne quelques exemples d'outils de profilage disponibles. </para>

<sect1 id="introduction-profiling">
<title
>Profilage</title>

<para
>Habituellement, quand on développe un programme, une des dernières étapes est d'optimiser les performances. C'est une perte de temps d'optimiser les fonctions rarement utilisées. Il est donc intéressant de savoir où votre programme passe le plus de temps. </para>

<para
>Pour du code séquentiel, la collecte des données statistiques des caractéristiques de l'exécution des programmes, comme par exemple le temps passé dans les fonctions ou dans les lignes de code est habituellement suffisant. C'est ce que l'on appelle le profilage. Le programme est exécuté sous le contrôle d'un outil de profilage, qui donne les résultats de l'exécution à la fin. Au contraire, pour du code parallèle, les problèmes de performance proviennent généralement de l'attente par un processeur de données d'un autre processeur. Comme ce temps d'attente ne peut habituellement être facilement attribué, il est préférable de générer ici des traces d'évènements horodatées. &kcachegrind; ne peut pas afficher ce type de données. </para>

<para
>Après analyse des données de profilage produites, il devrait être plus facile de voir les points chauds et les goulots d'étranglement du code. Par exemple, on peut vérifier les hypothèses par rapport au nombre d'appels, et les régions identifiées du code peuvent être optimisées. Après cela, on doit valider l'optimisation effectuée avec une autre exécution profilée. </para>
</sect1>

<sect1 id="introduction-methods">
<title
>Méthodes de profilage</title>

<para
>La mesure exacte du temps passé par des évènements se produisant pendant l'exécution d'une région de code (&pex;, une fonction) nécessite que soit effectué un rajout de code de mesure avant et après cette région. Ce code lit le temps ou bien un compteur global d'évènement, et calcule les différences. Par conséquent, le code original doit être changé avant l'exécution. C'est ce que l'on appelle l'instrumentation. L'instrumentation peut être faite par le programmeur lui-même, le compilateur, ou bien par le système d'exécution. Comme les régions intéressantes sont généralement imbriquées, la surcharge due à la mesure influence toujours la mesure elle-même. Ainsi, l'instrumentation doit être effectuée sélectivement et les résultats doivent être interprétés avec précaution. Bien sûr, ceci fait que l'analyse des performances se basant sur la mesure exacte est un processus très complexe.</para>

<para
>La mesure exacte est possible grâce à des compteurs matériels (ce qui inclut des compteurs s'incrémentant sur un tic de temps) fournis dans les processeurs modernes et qui sont incrémentés quand un évènement se produit. Comme nous voulons attribuer des évènements à des régions de code, sans utiliser de compteurs, nous devons gérer chaque évènement en incrémentant un compteur pour la région de code courante nous-mêmes. Faire ceci au niveau logiciel n'est bien sûr pas possible. Toutefois, si on part de l'hypothèse que la distribution des évènements sur le code source est identique quand on regarde à chaque nième évènement, au lieu de chaque évènement, nous avons construit une méthode de mesure réglable par rapport à la surcharge induite. On l'appelle l'échantillonnage. L'échantillonnage à base de temps (NdT : Time Based Sampling ou &TBS;) utilise un temporisateur pour regarder régulièrement le compteur de programme, afin de créer un histogramme sur le code du programme. L'échantillonnage à base d'évènements (NdT : Event Based Sampling ou &EBS;) exploite les compteurs matériels des processeurs modernes et utilise un mode dans lequel le gestionnaire d'interruptions est appelé sur les valeurs basses du compteur, en générant un histogramme de la distribution d'évènements correspondante. Dans le gestionnaire, le compteur d'évènement est toujours réinitialisé au <symbol
>n</symbol
> de la méthode d'échantillonnage. L'avantage de l'échantillonnage est que le code n'a pas besoin d'être modifié, mais ceci reste un compromis : la supposition d'au-dessus est correcte si<symbol
>n</symbol
> est petit, mais plus <symbol
>n</symbol
> est petit, plus la surcharge du gestionnaire d'interruptions est importante.</para>

<para
>Il existe une autre méthode de mesure qui est de simuler ce qui arrive au niveau de l'ordinateur quand on exécute un code donné, &cad; une simulation contrôlée de code. La simulation est toujours dépendante du modèle de la machine qui est plus ou moins précis. Cependant, pour des modèles très détaillés de machine, s'approchant de la réalité, le temps de simulation peut être assez inacceptable pour une utilisation courante. L'avantage est que l'on peut insérer dans un code donné un code de mesure/simulation aussi complexe qu'il soit sans perturber les résultats. Faire ceci directement avant l'exécution (ce que l'on appelle instrumentation dynamique), en utilisant le binaire original, est très confortable pour l'utilisateur : aucune recompilation n'est nécessaire. Cette méthode devient utilisable quand on ne simule que quelques parties de la machine avec un modèle simple. En outre, les résultats produits par des modèles simples sont souvent plus faciles à comprendre : le problème fréquent avec le vrai matériel est que les résultats incluent des effets de chevauchement de différentes parties de la machine.</para>
</sect1>

<sect1 id="introduction-tools">
<title
>Outils de profilage</title>

<para
>Le plus connu des outils de profilage est l'outil de la suite GCC, <application
>gprof</application
> : on doit compiler le programme avec l'option <option
>-pg</option
> ; le lancement du programme génère un fichier <filename
>gmon.out</filename
>, qui peut être transcrit dans une forme humainement lisible avec <command
>gprof</command
>. L'inconvénient principal de cette méthode est l'obligation de passer par une recompilation pour préparer l'exécutable, qui doit être lié de façon statique. La méthode utilisée ici est l'instrumentation générée par le compilateur. Celle-ci mesure les arcs d'appels se produisant dans les fonctions et en accord avec des compteurs d'appels, en conjonction avec un &TBS;, qui donne un histogramme de distribution du temps sur le code. En utilisant les deux informations, il est possible de calculer de manière heuristique le temps d'inclusion des fonctions, &cad; le temps passé dans une fonction ainsi que toutes les fonctions appelées depuis celle-ci. </para>

<para
>Pour une mesure exacte des évènements, il existe des librairies avec des fonctions capables de lire les compteurs de performance matériels. Les plus connus sont le patch PerfCtr pour &Linux; et les librairies indépendantes de l'architecture PAPI et PCL. Comme toujours, une mesure exacte nécessite une instrumentation du code, comme indiqué au-dessus. D'autres utilisent les librairies elles-mêmes ou utilisent des systèmes d'instrumentation automatiques comme ADAPTOR (pour l'instrumentation de sources FORTRAN), ou encore DynaProf (injection de code par DynInst).</para>

<para
>&oprofile; est un outil global de profilage système pour Linux utilisant l'échantillonnage. </para>

<para
>Dans beaucoup d'aspects, une manière agréable de profiler est d'utiliser &cachegrind; ou &callgrind;, qui sont des simulateurs utilisant l'environnement d'instrumentation d'exécution &valgrind;. Comme il n'y a pas besoin d'accéder aux compteurs matériels (souvent difficile avec les installations &Linux; actuelles), et comme les binaires devant être profilés n'ont pas besoin d'être modifiés, ceci est une bonne alternative à d'autres outils de profilage. L'inconvénient du ralentissement dû à la simulation peut être réduit en n'effectuant la simulation que sur les parties intéressantes du programme, et peut-être seulement sur quelques itérations d'une boucle. Sans instrumentation de la mesure/simulation, l'usage de &valgrind; ne provoque qu'un ralentissement d'un facteur de 3 à 5. Et si on n'est intéressé que par l'arbre d'appels et le nombre d'appels, le simulateur du cache peut être désactivé. </para>

<para
>La simulation du cache est la première étape dans l'approximation des temps réels. En effet, sur les systèmes modernes, l'exécution est très sensible à l'utilisation de ce que l'on appelle des <emphasis
>caches</emphasis
> (zones de mémoire petites et rapides, et qui permettent d'accélérer les accès répétés aux mêmes emplacements mémoire). &cachegrind; fait cette simulation du cache en interceptant les accès mémoires. Les données produites incluent le nombre d'accès sur la mémoire des instructions / des données, les échecs des caches de niveau L1 / L2, et elle met en relation les lignes du code source avec les fonctions du programme exécuté. En combinant ces compteurs d'échecs et en utilisant des temps de latence de processeurs connus, on peut faire une estimation du temps passé. </para>

<para
>&callgrind; est une extension de &cachegrind; qui construit l'arbre d'appels d'un programme à la volée, &cad; comment les fonctions s'appellent entre elles et combien d'évènements se produisent lors de l'exécution d'une fonction. De plus, les données de profilage devant être collectées peuvent être divisées en threads ou en contextes de chaînes d'appels. Il peut aussi fournir des données de profilage au niveau instruction afin de permettre l'annotation d'un code désassemblé. </para>
</sect1>

<sect1 id="introduction-visualization">
<title
>Visualisation</title>

<para
>Les outils de profilage produisent typiquement un nombre important de données. Le souhait de naviguer facilement dans l'arbre d'appels, ainsi que de passer rapidement d'un mode de tri des fonctions et d'affichage des différents types d'évènements, a motivé la création d'une application &GUI; (Interface graphique utilisateur) pour accomplir cela. </para>

<para
>&kappname; est un outil d'affichage de données de profilage permettant d'exaucer ces souhaits. Même si il a été programmé en vue de naviguer dans les données de &cachegrind; et &calltree;, il existe toutefois des convertisseurs permettant d'afficher les données de profilage produites par d'autres outils. Une description du format des fichiers &cachegrind;/&callgrind; est donnée dans l'appendice. </para>

<para
>En plus d'une liste de fonctions triées en fonction des métriques des coûts inclusifs ou exclusifs, et éventuellement groupées par fichier source, librairie partagée ou classe C++, &kappname; propose des vues différentes et variées pour une fonction sélectionnée, à savoir <itemizedlist>
<listitem
><para
>une vue de l'arbre d'appel, qui montre une section de l'arbre d'appel autour de la fonction sélectionnée, </para>
</listitem>
<listitem
><para
>une vue de la carte de l'arbre, qui permet d'afficher la relation entre appels imbriqués ainsi que la métrique du coût inclusif pour détecter visuellement et rapidement les fonctions à problèmes, </para>
</listitem>
<listitem
><para
>les vues du code source et de l'annotation assembleur, permettant de voir les détails des coûts associés aux lignes du code source et des instructions assembleur.</para>
</listitem>
</itemizedlist>

</para>
</sect1>
</chapter>

<chapter id="using-kcachegrind">
<title
>Utiliser &kcachegrind;</title>

<sect1 id="using-profile">
<title
>Générer les données à afficher</title>

<para
>Tout d'abord, il faut générer les données de performance en mesurant les aspects des caractéristiques de l'exécution d'une application. Pour cela, il faut utiliser un outil de profilage. &kcachegrind; n'inclut pas d'outil de profilage, mais est prévu pour fonctionner avec &callgrind;. En utilisant un convertisseur, il peut aussi être utilisé pour afficher les données produites par &oprofile;. Même si l'objectif de ce manuel n'est pas de documenter le profilage avec ces outils, la prochaine section fournit des petits tutoriels afin que vous puissiez démarrer. </para>

<sect2>
<title
>&callgrind;</title>

<para
>&callgrind; est un composant de <ulink url="http://valgrind.org"
>&valgrind;</ulink
>. Notez qu'il était précédemment nommé &calltree;, mais ce nom était trompeur. </para>

<para
>L'usage le plus courant est de démarrer votre application en préfixant la ligne de commande par <userinput
><command
>valgrind</command
> <option
>--tool=callgrind</option
> </userinput
>, comme par exemple : <blockquote
><para
><userinput
> <command
>valgrind</command
> <option
>--tool=callgrind</option
> <replaceable
>mon_programme</replaceable
> <replaceable
>mes_arguments</replaceable
> </userinput
></para
></blockquote
> À la fin du programme, un fichier <filename
>callgrind.out.<replaceable
>pid</replaceable
></filename
> est généré. Ce fichier peut être chargé dans &kcachegrind;. </para>

<para
>Un usage plus avancé est de générer des données de profilage quand une fonction donnée de votre application est appelée. Par exemple, pour &konqueror;, pour ne voir les données de profilage que pour le rendu d'une page web, vous pouvez décider de générer les données quand vous sélectionnez l'élément du menu <menuchoice
><guimenu
>Affichage</guimenu
><guimenuitem
>Recharger</guimenuitem
></menuchoice
>. Ceci correspond à un appel à <methodname
>KonqMainWindow::slotReload</methodname
>. Utilisez : <blockquote
><para
><userinput
> <command
>valgrind</command
> <option
>--tool=callgrind</option
> <option
>--dump-before=KonqMainWindow::slotReload</option
> <replaceable
>konqueror</replaceable
> </userinput
></para
></blockquote
> Ceci va produire plusieurs fichiers de données de profilage avec un numéro additionnel séquentiel à la fin du nom du fichier. Un fichier sans un tel nombre à la fin (se terminant seulement par le PID du processus) sera aussi produit. En chargeant ce fichier dans &kcachegrind;, tous les autres fichiers seront aussi chargés, et peuvent être affichés dans la <guilabel
>synthèse des parties</guilabel
> etdans la liste des <guilabel
>parties</guilabel
>. </para>

</sect2>

<sect2>
<title
>&oprofile;</title>

<para
>&oprofile; est disponible sur sa page web d'accueil <ulink url="http://oprofile.sf.net"
> http://oprofile.sf.net</ulink
>. Suivez les instructions d'installation du site web. Mais, avant de faire cela, vérifiez toutefois que votre distribution ne le fournisse pas déjà en tant que paquetage (comme &SuSE;). </para>

<para
>Le profilage au niveau système n'est autorisé que pour l'administrateur, car toutes les actions sur le système peuvent être observées. C'est pourquoi ce qui va suivre doit être fait en tant qu'administrateur. Tout d'abord, configurez le processus de profilage, en utilisant la commande de la &GUI; (interface graphique utilisateur) <command
>oprof_start</command
> ou l'outil en ligne de commande <command
>opcontrol</command
>. La configuration standard est normalement le mode compteur (&TBS;, voir introduction). Pour démarrer la mesure, lancez <userinput
><command
>opcontrol</command
><option
>-s</option
></userinput
>. Ensuite lancez l'application à profiler, et après, lancez <userinput
><command
>opcontrol</command
><option
>-d</option
> </userinput
>. Ceci va écrire les résultats de la mesure dans des fichiers situés dans le dossier <filename class="directory"
>/var/lib/oprofile/samples/</filename
>. Pour pouvoir afficher les données dans &kcachegrind;, lancez la commande suivante dans un dossier vide : <blockquote
><para
><userinput
> <command
>opreport</command
> <option
>-gdf</option
> | <command
>op2callgrind</command
> </userinput
></para
></blockquote
>. Ceci va produire un nombre important de fichiers, un pour chaque programme qui s'exécutait sur le système. Chacun peut être chargé indépendamment dans &kcachegrind;. </para>

</sect2>
</sect1>

<sect1 id="using-basics">
<title
>Bases de l'interface utilisateur</title>

<para
>Quand vous lancez &kcachegrind; avec un fichier de données de profilage en tant qu'argument, ou après en avoir chargé un avec <menuchoice
><guimenu
>Fichier</guimenu
> <guimenuitem
>Ouvrir</guimenuitem
></menuchoice
>, vous verrez une barre de navigation sur la gauche contenant la liste des fonctions et, à droite de la partie principale, une aire des vues pour la fonction sélectionnée. L'aire des vues peut être configurée pour afficher plusieurs vues simultanément. </para>

<para
>Lors de la première utilisation, cette zone sera divisée horizontalement en deux parties, chacune possédant des affichages sélectionnables par onglets. Pour déplacer les affichages, utilisez le menu contextuel des onglets, et ajustez les séparations entre affichages. Pour changer rapidement de type d'affichage utilisez <menuchoice
><shortcut
><keycombo action="simul"
>&Ctrl;<keycap
>→</keycap
> </keycombo
></shortcut
> <guimenu
>Affichage</guimenu
><guisubmenu
>Présentation</guisubmenu
> <guimenuitem
>Aller au suivant</guimenuitem
></menuchoice
> et <menuchoice
><shortcut
><keycombo action="simul"
>&Ctrl;<keycap
>←</keycap
> </keycombo
></shortcut
> <guimenu
>Affichage</guimenu
><guisubmenu
>Présentation</guisubmenu
> <guimenuitem
>Aller au précédent</guimenuitem
></menuchoice
>. </para>

<para
>Le type d'évènement actif est important pour la vue : pour &callgrind;, c'est par exemple le nombre d'échecs du cache ou l'estimation du cycle ; pour &oprofile;, c'est le <quote
>compteur</quote
> dans le plus simple cas. Vous pouvez changer le type d'évènement par une combobox dans la barre d'outils ou dans la vue <guilabel
>type d'évènement</guilabel
>. Un premier aperçu des caractéristiques de l'exécution devrait être donné quand vous sélectionnez la fonction <function
>main</function
> dans la liste de gauche, et regardez la vue de l'arbre d'appels. Là vous voyez les appels se produisant dans votre programme. Notez que la vue du graphe d'appels ne montre que les fonctions avec un nombre d'évènements élevé. En double-cliquant sur une fonction dans le graphe, celui-ci change pour afficher les fonctions appelées autour de celle sélectionnée. </para>

<para
>Pour explorer plus profondément l'interface graphique, vous pouvez aussi consulter, en plus de ce manuel, la section documentation du <ulink url="http://kcachegrind.sf.net"
>site web</ulink
>. De plus, chaque composant de &kcachegrind; est fourni avec l'aide <quote
>Qu'est-ce que c'est ? </quote
>. </para>
</sect1>

</chapter>


<chapter id="kcachegrind-concepts">
<title
>Concepts de base</title>

<para
>Ce chapitre explique quelques concepts de &kcachegrind;, et introduit les termes utilisés dans l'interface. </para>

<sect1 id="concepts-model">
<title
>Le modèle de données pour les données de profilage</title>

<sect2>
<title
>Entités de coût</title>

<para
>Les compteurs de coût des types d'évènement (comme les échecs du cache L2) sont attribués aux entités de coût, qui sont des éléments en relation avec le code source ou des structures de données d'un programme donné. Les entités de coût ne sont pas seulement un code simple ou des positions de données, mais aussi des tuples de position. Par exemple, un appel a une source et une cible, ou bien une adresse de données peut avoir un type de données et une position dans le code où son allocation s'est effectuée. </para>

<para
>Les entités de coût connues de &kcachegrind; sont données ci-dessous. Les positions simples :<variablelist
> <varlistentry
> <term
>Instruction</term
> <listitem
><para
> Une instruction assembleur à l'adresse spécifiée </para
></listitem
> </varlistentry
> <varlistentry
> <term
>Ligne source d'une fonction</term
> <listitem
><para
>Toutes les instructions que le compilateur (par l'intermédiaire des informations de débogage) associe à une ligne donnée spécifiée par le nom du fichier source et le numéro de la ligne, et qui sont exécutées dans le contexte de quelques fonctions. Le dernier est nécessaire parce qu'une ligne source à l'intérieur d'une fonction inline peut apparaître dans le contexte de fonctions multiples. Les instructions sans association avec une ligne du code source courant sont associées à la ligne numéro 0 du fichier <filename
>???</filename
>. </para
></listitem
> </varlistentry
> <varlistentry
> <term
> Fonction</term
> <listitem
><para
> Toutes les lignes d'une fonction donnée constituent la fonction elle-même. Une fonction est spécifiée, s'ils sont disponibles, par son nom et sa position dans quelque objets binaire. Ce dernier est nécessaire parce que les objets binaires d'un seul programme peuvent chacun avoir des fonctions avec le même nom (on peut y accéder &pex; avec <function
>dlopen</function
>ou <function
>dlsym</function
> ; l'éditeur de lien dynamique résout les fonctions dans un ordre de recherche donné des objets binaires utilisés). Si un outil de profilage ne peut détecter le nom du symbole d'une fonction, &pex; parce que l'information de débogage n'est pas disponible, soit l'adresse de la première instruction exécutée est utilisée, soit <function
> ??? </function
>. </para
></listitem
> </varlistentry
> <varlistentry
> <term
>Objet binaire</term
> <listitem
><para
> Toutes les fonctions dont le code se situe à l'intérieur d'un objet binaire donné, que ce soit l'exécutable principal (NdT : « main »), ou encore une librairie partagée. </para
></listitem
> </varlistentry
> <varlistentry
> <term
>Fichier source</term
> <listitem
><para
> Toutes les fonctions dont la première instruction est associée à une ligne d'un fichier source donné.</para
></listitem
> </varlistentry
> <varlistentry
> <term
>Classe</term
> <listitem
><para
> Les noms des symboles des fonctions sont généralement ordonnés hiérarchiquement dans des espaces de noms, &pex; les espaces de noms C++, ou les classes des langages orientés objet. Ainsi une classe peut contenir des fonctions d'une classe ou de classes embarquées</para
></listitem
> </varlistentry
> <varlistentry
> <term
> Partie d'un profilage</term
> <listitem
><para
> Certaines sections du temps d'exécution d'un profilage, avec un identifiant de thread (fil ou suite d'opérations successives, NdT) donné, un identifiant de processus, et la ligne de commande exécutée.</para
></listitem
> </varlistentry
> </variablelist
> Comme on peut le voir grâce à la liste, un ensemble d'entités de coût définit souvent une autre entité de coût. Ainsi il y a une hiérarchie d'imbrication des entités de coût. </para>

<para
>Tuples des positions : <itemizedlist
><listitem
><para
>Appel d'une adresse d'instruction vers une fonction cible. </para
></listitem
><listitem
><para
> Appel d'une fonction du source vers une fonction cible. </para
></listitem
><listitem
><para
> Appel d'une fonction du source vers une fonction cible. </para
></listitem
><listitem
><para
>Saut (in)conditionnel d'une ligne du source vers une instruction cible. </para
></listitem
><listitem
><para
>Saut (in)conditionnel d'une source vers une ligne cible. </para
></listitem
></itemizedlist
>Les sauts entre les fonctions ne sont pas autorisés, car cela est absurde dans un arbre d'appels. Ainsi, les constructions telles la gestion des exceptions et les sauts longs en C doivent être traduits pour se mettre dans la pile d'appels comme demandé. </para>

</sect2>


<sect2>
<title
>Types d'évènement</title>

<para
>Des types d'évènements arbitraires peuvent être spécifiés dans les données de profilage en leur donnant un nom. Leur coût relié à une entité de coût est un entier sur 64 bits. </para>
<para
>Les types d'évènement dont les coûts sont spécifiés dans le fichier de données de profilage sont appelés évènement réels. En plus, on peut spécifier des formules pour les types d'évènement calculés à partir d'évènement réels, que l'on appelle évènements hérités. </para>
</sect2>

</sect1>

<sect1 id="concepts-state">
<title
>État de la vue</title>

<para
>L'état de la vue d'une fenêtre de &kcachegrind; inclut : <itemizedlist
><listitem
><para
>le type d'évènement primaire et secondaire choisi pour l'affichage, </para
></listitem
><listitem
><para
>le regroupement de fonction (utilisé dans la liste <guilabel
>Profilage des fonctions</guilabel
> et dans la coloration des entités), </para
></listitem
><listitem
><para
>les parties du profilage dont les coûts doivent être inclus dans la vue, </para
></listitem
><listitem
><para
>une entité active de coût (&pex;, une fonction sélectionnée de la barre latérale Profilage de la fonction), </para
></listitem
><listitem
><para
>une entité de coût sélectionnée.</para
></listitem
></itemizedlist
> Cet état influence les vues. </para>

<para
>Les vues sont toujours affichées pour une entité de coût, celle qui est active. Quand une vue donnée est inappropriée pour une entité de coût, elle est désactivée (&pex; quand on sélectionne un objet &ELF; en double-cliquant dans la liste des groupes, l'annotation du code source n'a aucun sens). </para>

<para
>Par exemple, pour une fonction active, la liste des fonctions appelées montre toutes les fonctions appelées par la fonction active. On peut sélectionner une de ces fonctions sans la rendre active. De plus, si le graphe d'appels est montré à côté, il va automatiquement sélectionner la même fonction. </para>

</sect1>

<sect1 id="concepts-guiparts">
<title
>Éléments de l'interface graphique</title>

<sect2>
<title
>Barres latérales</title>
<para
>Les <foreignphrase
>sidedocks</foreignphrase
> ou barres latérales sont des fenêtres latérales qui peuvent être placées contren'importe quelle bordure d'une fenêtre de &kcachegrind;. Elles contiennent toujours une liste d'entités de coût triées d'une manière ou d'une autre. <itemizedlist>
<listitem
><para
>Le <guilabel
>Profil de Fonction</guilabel
> est une liste des fonctions avec les coûts inclusifs et exclusifs, le nombre d'appels, le nom et la position des fonctions. </para
></listitem>
<listitem
><para>
<guilabel
>Synthèse des parties</guilabel>
</para
></listitem>
<listitem
><para>
<guilabel
>Pile d'appels</guilabel>
</para
></listitem>
</itemizedlist>
</para>
</sect2>

<sect2>
<title
>Zone des vues</title>
<para
>L'aire des vues, se situant généralement dans la partie droite de la fenêtre principale de &kcachegrind;, est constituée d'une (par défaut) ou de plusieurs vues d'onglets, rangées horizontalement ou verticalement. Chaque vue d'onglet contient plusieurs vues différentes pour une seule entité de coût à un instant donné. Le nom de cette entité est indiqué en haut de la vue d'onglets. S'il y a plusieurs vues d'onglets, une seulement est active. Le nom de l'entité dans la vue d'onglets active est affiché en gras, et détermine l'entité de coût active de la fenêtre de &kcachegrind;. </para>
</sect2>

<sect2>
<title
>Aires d'une vue d'onglets</title>
<para
>Chaque vue d'onglets peut contenir jusqu'à quatre aires d'affichage, nommées Haut, Droite, Gauche, Bas. Chaque aire peut contenir plusieurs vues empilées. La partie visible d'une aire est sélectionnée par la barre d'onglets. Les barres d'onglets de l'aire en haut à droite sont en haut, les barres d'onglets de l'aire en bas à gauche sont en bas. Vous pouvez spécifier quel type de vue doit aller dans chaque aire en utilisant les menus contextuels des onglets. </para>
</sect2>

<sect2>
<title
>Affichage synchronisé par une entité sélectionnée dans un onglet</title>
<para
>En plus d'une entité active, chaque vue d'onglets a une entité sélectionnée. Comme la plupart des types de vues montre plusieurs entités avec celle qui est active à peu près centrée, vous pouvez changer l'élément sélectionné en naviguant dans une vue (en cliquant avec la souris ou en utilisant le clavier). Généralement, les éléments sélectionnés sont affichés en surbrillance. En changeant l'entité sélectionnée dans une des vues de la vue d'onglets, toutes les autres vues dans la vue d'onglets mettent logiquement la nouvelle entité sélectionnée en surbrillance. </para>
</sect2>

<sect2>
<title
>Synchronisation entre les vues d'onglets</title>
<para
>Si il y a plusieurs vues d'onglets, un changement de sélection dans une des vues d'onglets mène à un changement d'activation dans la vue d'onglets suivante. Qu'elle soit en dessous de cette dernière ou dessous celle-ci. Cette sorte de lien doit permettre, par exemple, de naviguer rapidement dans les graphes d'appels. </para>
</sect2>

<sect2>
<title
>Dispositions</title>
<para
>La disposition de toutes les vues d'onglets d'une fenêtre peut être enregistrée (<menuchoice
><guimenu
>Affichage</guimenu
><guisubmenu
>Disposition des vues</guisubmenu
></menuchoice
>). Après avoir dupliqué la disposition courante (<menuchoice
><shortcut
><keycombo action="simul"
>&Ctrl;<keycap
>+</keycap
></keycombo
></shortcut
><guimenu
>Affichage</guimenu
><guisubmenu
>Disposition des vues</guisubmenu
><guimenuitem
>Dupliquer</guimenuitem
></menuchoice
> et changé quelques tailles ou bougé une vue vers une autre aire de la vue d'onglets, vous pouvez rapidement commuter entre la nouvelle disposition et l'ancienne par <keycombo action="simul"
> &Ctrl;<keycap
>←</keycap
></keycombo
> et <keycombo action="simul"
>&Ctrl; <keycap
>→</keycap
></keycombo
>. L'ensemble des dispositions sera enregistré entre les sessions de &kcachegrind; pour une même commande profilée. Vous pouvez faire que l'ensemble courant des dispositions soit celui par défaut pour les nouvelles sessions de &kcachegrind;, ou bien revenir à l'ensemble des dispositions par défaut. </para>
</sect2>
</sect1>

<sect1 id="concepts-sidedocks">
<title
>Barres latérales</title>

<sect2>
<title
>Profilage aplati</title>
<para
>Le <guilabel
>profilage aplati</guilabel
> contient une liste de groupes et une liste de fonctions. La liste des groupes contient tous les groupes où le coût a été enregistré, en fonction du type de groupe choisi. La liste des groupes est cachée quand le regroupement est désactivé. </para>
<para
>La liste des fonctions contient les fonctions d'un regroupement sélectionné (ou toutes les fonctions si le regroupement est désactivé), triées par colonne, &pex; les coûts propres ou inclusifs enregistrés dedans. Le nombre de fonctions affichées dans la liste est limité, configurable dans <menuchoice
><guimenu
>Configuration</guimenu
><guimenuitem
>Configurer KCachegrind</guimenuitem
></menuchoice
>. </para>
</sect2>

<sect2>
<title
>Synthèse des parties</title>
<para
>Dans une exécution de profilage, plusieurs fichiers de données de profilage peuvent être produits et être chargés ensemble dans &kcachegrind;. La barre latérale Synthèse des parties les montre, en les triant horizontalement par date de création, les tailles de rectangle étant proportionnelles au coût enregistré dans chaque partie. Vous pouvez sélectionner une ou plusieurs parties pour obliger les coûts affichés dans les autres vues de &kcachegrind; à s'appliquer uniquement sur ces parties. </para>
<para
>Les parties sont encore sous-divisées en un mode partitionnement et un mode partage des coûts inclusifs : <variablelist>
<varlistentry>
<term
><guilabel
>Mode de partitionnement</guilabel
></term>
<listitem
><para
>Partitionnement : vous voyez le partitionnement dans des groupes pour une partie des données de profilage, en accord avec le type de groupe sélectionné. Par exemple, si les groupes objet &ELF; sont sélectionnés, vous verrez des rectangles colorés pour chaque objet &ELF; utilisé (bibliothèque partagée ou exécutable), qui auront une taille proportionnelle au coût enregistré dedans. </para
></listitem>
</varlistentry>
<varlistentry>
<term
><guilabel
>Mode Diagramme</guilabel
></term>
<listitem
><para
>Un rectangle montrant le coût inclusif de la fonction active dans la partie est affiché. Celui-ci est partagé pour afficher les coûts inclusifs des fonctions appelées. </para
></listitem>
</varlistentry>
</variablelist>
</para>
</sect2>

<sect2>
<title
>Pile d'appels</title>
<para
>C'est une pile d'appels purement fictive, qui est la <quote
>plus probable</quote
>. Elle est construite en mettant au début la fonction active courante, puis en ajoutant les fonctions appelantes/appelées avec les plus hauts coûts en haut et en bas. </para>
<para
>Les colonnes <guilabel
>coût</guilabel
> et <guilabel
>appels</guilabel
> montrent le coût enregistré pour tous les appels de la fonction dans la ligne au-dessus. </para>
</sect2>
</sect1>

<sect1 id="concepts-views">
<title
>Vues</title>

<sect2>
<title
>type d'évènement</title>
<para
>La liste <guilabel
>Type d'évnènement</guilabel
> montre tous les types de coût disponibles, ceux correspondant, et le coût inclusif de la fonction active courante pour ce type d'évènement. </para>
<para
>En choisissant un type d'évènement dans la liste, vous changez le type des coûts montré partout dans &kcachegrind; par celui sélectionné. </para>
</sect2>

<sect2>
<title
>Listes des appels</title>
<para
>Ces listes montrent les appels et les fonctions appelées de la fonction active courante. Avec <guilabel
>Toutes fonctions appelantes</guilabel
> et <guilabel
>Toutes fonctions appelées</guilabel
> sont désignées toutes les fonctions pouvant être accédées dans le sens des appelantes ou des appelées, même si d'autres fonctions se trouvent entre elles. </para>

<para
>Les vues de liste des appels inclut : <itemizedlist>
<listitem
><para
><guilabel
>Appelants</guilabel
> en direct</para
></listitem>
<listitem
><para
><guilabel
>Appelées</guilabel
> en direct</para
></listitem>
<listitem
><para
><guilabel
>Toutes les fonctions appelantes</guilabel
></para
></listitem>
<listitem
><para
><guilabel
>Toutes les fonctions appelées</guilabel
></para
></listitem>
</itemizedlist>
</para>
</sect2>

<sect2>
<title
>Cartes</title>
<para
>Une vue en arborescence du type d'évènement principal, en haut ou en bas de la hiérarchie d'appel. Chaque rectangle coloré représente une fonction, avec une taille approximativement proportionnelle au coût enregistré ici pendant que la fonction active s'exécute (cependant, il y a des contraintes de représentation graphique). </para>
<para
>Pour la <guilabel
>carte des fonctions appelantes</guilabel
>, le graphique montre la hiérarchie interne de toutes les fonctions appelant la fonction activée à ce moment ; pour la <guilabel
>carte des fonctions appelées</guilabel
>, il montre celle de toutes les fonctions appelées (par la fonction activée à ce moment) </para>
<para
>Les options d'apparence sont disponibles dans le menu contextuel. Pour avoir des proportions exactes, choisissez <guimenuitem
>Cacher les bordures incorrectes</guimenuitem
>. Comme ce mode peut s'avérer très chronophage, vous pourriez vouloir limiter par anticipation le niveau maximum de représentation graphique. <guilabel
>Meilleur</guilabel
> détermine la direction de partage pour les enfants à partir du ratio d'aspect de leur parent. <guilabel
>Toujours meilleur</guilabel
> décide de l'espace restant pour chaque enfant du même parent. <guilabel
>Ignorer les proportions</guilabel
> prend l'espace pour dessiner le nom de la fonction avant de dessiner les enfants. Notez que les proportions peuvent être lourdement faussées. </para>
<para
>La navigation par le clavier est disponible avec les touches gauche/droite pour parcourir les enfants du même parent, et haut/bas pour aller au niveau au-dessus/en dessous le plus proche. La touche &Enter; active l'élément courant. </para>
</sect2>

<sect2>
<title
>Graphe des appels</title>
<para
>Cette vue montre le graphe d'appel autour de la fonction active. Le coût montré est seulement le coût enregistré pendant que la fonction active s'exécutait ; &cad; le coût montré pour <function
>main()</function
> (si elle est visible) doit être le même que le coût de la fonction active, puisque c'est la partie du coût inclusif de <function
>main()</function
> enregistré pendant que la fonction active s'exécutait. </para>
<para
>Pour les cycles, les flèches d'appels bleues indiquent que c'est un appel artificiel, qui ne s'est jamais produit en réalité, rajouté pour un affichage correct. </para>
<para
>Si le graphe est plus large que l'aire du composant, un panneau d'aperçu est affiché dans un coin. Il y a des options de vue identiques à celles de la carte de l'arbre d'appels ; la fonction sélectionnée est mise en surbrillance. </para>
</sect2>

<sect2>
<title
>Annotations</title>
<para
>Les listes annotées de source ou d'assembleur montre les lignes du code source ou les instructions désassemblées de la fonction couramment active, ainsi que le coût (propre) enregistré lors de l'exécution du code d'une ligne du source ou d'une instruction. S'il y a eu appel, les lignes avec les détails sur l'appel sont insérées dans le code source : le coût (inclusif) dépensé dans l'appel, le nombre d'appels effectués, et la destination de l'appel. </para>
<para
>Sélectionnez une telle ligne d'information d'appel pour activer la destination de l'appel. </para>
</sect2>
</sect1>

</chapter>


<chapter id="commands">
<title
>Les éléments de menus / barres d'outils</title>

<sect1 id="kcachegrind-mainwindow">
<title
>La fenêtre principale de &kcachegrind;</title>

<sect2>
<title
>Le menu <guimenu
>Fichier</guimenu
></title>
<para>
<variablelist>

<varlistentry>
<term
><menuchoice
><shortcut
> <keycombo
>&Ctrl;<keycap
>N</keycap
></keycombo
> </shortcut
> <guimenu
>Fichier</guimenu
><guimenuitem
>Nouveau</guimenuitem
> </menuchoice
></term>
<listitem
><para
><action
>Ouvre une fenêtre de haut niveau vide</action
> dans laquelle vous pouvez charger des données de profilage. Cette action n'est pas vraiment nécessaire, car <menuchoice
><guimenu
>Fichier</guimenu
><guimenuitem
>Ouvrir</guimenuitem
></menuchoice
> vous donnera une nouvelle fenêtre de haut niveau si la fenêtre courante affiche déjà des données. </para
></listitem>
</varlistentry>

<varlistentry>
<term
><menuchoice
><shortcut
> <keycombo
>&Ctrl;<keycap
>O</keycap
></keycombo
> </shortcut
> <guimenu
>Fichier</guimenu
><guimenuitem
>Ouvrir</guimenuitem
> </menuchoice
></term>
<listitem>
<para
><action
>Affiche le dialogue &kde; de sélection de fichier</action
> afin que vous puissiez choisir le fichier de données de profilage à charger. S'il y a déjà des données affichées dans la fenêtre courante de premier niveau, ceci va ouvrir une nouvelle fenêtre. Si vous voulez ouvrir des données additionnelles de profilage dans la fenêtre courante, utilisez <menuchoice
><guimenu
>Fichier</guimenu
><guimenuitem
>Ajouter</guimenuitem
></menuchoice
>. </para>
<para
>Le nom des fichiers de données de profilage se termine habituellement par <literal role="extension"
><replaceable
>pid</replaceable
>.<replaceable
>partie</replaceable
>-<replaceable
>threadID</replaceable
></literal
>, où <replaceable
>partie</replaceable
> et <replaceable
>threadID</replaceable
> sont facultatifs.  <replaceable
>pid</replaceable
> et <replaceable
>partie</replaceable
> sont utilisés pour les multiples fichiers de données de profilage recueillis lors de l'exécution d'une application.En chargeant un fichier se terminant seulement par <literal role="extension"
><replaceable
>pid</replaceable
></literal
>, les fichiers de données éventuellement présents pour cette exécution, mais avec des terminaisons additionnelles, seront également chargés. </para>
<informalexample
><para
>s'il existe des fichiers de données de profilage <filename
>cachegrind.out.123</filename
> et <filename
>cachegrind.out.123.1</filename
>, en chargeant le premier, le second sera chargé automatiquement. </para
></informalexample
></listitem>
</varlistentry>

<varlistentry>
<term
><menuchoice
><guimenu
>Fichier</guimenu
><guimenuitem
>Ajouter</guimenuitem
> </menuchoice
></term>
<listitem
><para
><action
>Ajoute un fichier de données de profilage</action
> dans la fenêtre courante. Vous pouvez ainsi forcer le chargement de multiples fichiers de données dans la même fenêtre de premier niveau, même s'ils ne sont pas de la même exécution, comme donné par la convention de nommage des fichiers de données de profilage. Utilisez cela par exemple pour des comparaisons côte-à-côte. </para
></listitem>
</varlistentry>

<varlistentry>
<term
><menuchoice
><shortcut
> <keycombo
><keycap
>F5</keycap
></keycombo
> </shortcut
> <guimenu
>Fichier</guimenu
> <guimenuitem
>Recharger</guimenuitem
> </menuchoice
></term>
<listitem
><para
><action
>Recharge les données de profilage</action
>. Ceci est utile après qu'un autre fichier de données de profilage est généré par l'exécution d'une application déjà chargée. </para
></listitem>
</varlistentry>

<varlistentry>
<term
><menuchoice
><shortcut
> <keycombo
>&Ctrl;<keycap
>Q</keycap
></keycombo
> </shortcut
> <guimenu
>Fichier</guimenu
> <guimenuitem
>Quitter</guimenuitem
> </menuchoice
></term>
<listitem
><para
><action
>Quitte</action
> &kappname;</para
></listitem>
</varlistentry>
</variablelist>
</para>

</sect2>

</sect1>
</chapter>

<chapter id="faq">
<title
>Questions et Réponses</title>
&reporting.bugs; &updating.documentation; <qandaset id="faqlist">


<qandaentry>
<question>
<para
>À quoi sert &kcachegrind; ? Je n'en ai aucune idée. </para>
</question>
<answer>
<para
>&kcachegrind; est utile dans le stade final du développement d'un logiciel, appelé le profilage. Si vous ne développez pas d'applications, vous n'avez pas besoin de &kcachegrind;. </para>
</answer>
</qandaentry>

<qandaentry>
<question>
<para
>Quelle est la différence entre <guilabel
>Incl.</guilabel
> et <guilabel
>Propre</guilabel
> ? </para>
</question>
<answer>
<para
>Ce sont des attributs de coût pour les fonctions concernant certains types d'évènements. Comme les fonctions peuvent s'appeler entre elles, il paraît logique de distinguer le coût de la fonction elle-même (<quote
>Coût propre</quote
>) et le coût incluant toutes les fonctions appelées (<quote
>Coût inclusif</quote
>). <quote
>Propre</quote
> est aussi remplacé certaines fois par <quote
>Exclusif</quote
>. </para>
<para
>Ainsi, par exemple pour <function
>main()</function
>, vous aurez toujours un coût inclusif de presque 100 %, alors que le coût propre est négligeable, le travail réel s'effectuant dans une autre fonction. </para>
</answer>
</qandaentry>

<qandaentry>
<question>
<para
>La barre d'outils/de menus de &kcachegrind; est spartiate. Est-ce normal ?</para>
</question>
<answer>
<para
>&kcachegrind; a probablement été mal installé sur votre système. Il est recommandé de le compiler avec comme préfixe d'installation votre dossier système &kde; de base, comme par exemple <userinput
><command
>configure <option
>--prefix=<replaceable
>/opt/kde4</replaceable
></option
></command
> ; <command
>make install</command
></userinput
>. Si vous choisissez un autre dossier, comme <filename class="directory"
>$<envar
>HOME</envar
>/kde</filename
>, vous devez positionner la variable d'environnement <envar
>KDEDIR</envar
> sur ce dossier avant de lancer &kcachegrind;. </para>
</answer>
</qandaentry>

<qandaentry>
<question>
<para
>Si je double-clique sur une fonction en bas de la vue de <guilabel
>l'arbre d'appel</guilabel
>, il affiche le même coût pour la fonction <function
>main()</function
> que pour la fonction sélectionnée. N'est-ce pas supposé rester constant à 100 % ? </para>
</question>
<answer>
<para
>Vous avez activé une fonction en dessous de<function
> main()</function
> qui de toute évidence coûte moins que <function
>main()</function
> elle-même. Pour chaque fonction, on ne montre de la partie du coût total de la fonction enregistrée alors que la fonction <emphasis
>activée</emphasis
> s'exécutait. C'est-à-dire que le coût affiché pour toute fonction ne peut jamais être plus élevé que le coût de la fonction activée. </para>
</answer>
</qandaentry>


</qandaset>
</chapter>


<glossary>

<glossentry id="costentity">
<glossterm
>Entité de coût</glossterm>
<glossdef
><para
>C'est un élément abstrait lié à un code source auquel on peut attribuer des décomptes d'évènements. Les dimensions des entités de coût sont la localisation dudit code (&pex;, ligne du source, fonction), la localisation des données (&pex;, type de donnée accédée, donnée), la localisation de l'exécution (&pex;, thread, processus), et les couples ou les triplets des positions mentionnées au-dessus (&pex;, appels, accès à un objet à partir d'une instruction, donnée expulsée du cache).</para
></glossdef>
</glossentry>

<glossentry id="eventcosts">
<glossterm
>Coûts d'évènement</glossterm>
<glossdef
><para
>C'est la somme des évènements d'un certain type d'évènement se produisant pendant que l'exécution est liée à quelques entités de coût. Le coût est attribué à l'entité.</para
></glossdef>
</glossentry>

<glossentry id="eventtype">
<glossterm
>Type d'évènement</glossterm>
<glossdef
><para
>C'est la sorte de l'évènement dont les coûts peuvent être attribués à une entité de coût. Il existe des types d'évènements réels et des types d'évènements hérités.</para
></glossdef>
</glossentry>

<glossentry id="inheritedeventtype">
<glossterm
>Type d'évènement hérité</glossterm>
<glossdef
><para
>C'est un type d'évènement virtuel, seulement visible dans une vue, et qui est défini par une formule fondée sur des types d'évènements réels.</para
></glossdef>
</glossentry>

<glossentry id="profiledatafile">
<glossterm
>Fichier de données de profilage</glossterm>
<glossdef
><para
>C'est un fichier contenant des données mesurées dans une expérience de profilage (ou une partie), ou produite par post-traitement d'une trace. Sa taille est généralement proportionnelle linéairement à la taille du code du programme.</para
></glossdef>
</glossentry>

<glossentry id="profiledatapart">
<glossterm
>Partie de données de profilage</glossterm>
<glossdef
><para
>Données d'un fichier de données de profilage.</para
></glossdef>
</glossentry>

<glossentry id="profileexperiment">
<glossterm
>Expérience de profilage</glossterm>
<glossdef
><para
>C'est une exécution d'un programme, supervisée par un outil de profilage, qui peut produire plusieurs fichiers de données de profilage à partir de parties ou de threads de l'exécution.</para
></glossdef>
</glossentry>

<glossentry id="profileproject">
<glossterm
>Projet de profilage</glossterm>
<glossdef
><para
>C'est une configuration pour les expériences de profilage utilisée pour un programme qui doit être profilé, peut-être dans plusieurs versions. Comparer des données de profilage n'a généralement de sens qu'entre données de profilage produites dans des expériences sur un seul projet de profilage.</para
></glossdef>
</glossentry>

<glossentry id="profiling">
<glossterm
>Profilage</glossterm>
<glossdef
><para
>C'est le processus de collecte d'informations statistiques sur les caractéristiques en temps réel des exécutions d'un programme.</para
></glossdef>
</glossentry>

<glossentry id="realeventtype">
<glossterm
>Type d'évènement réel</glossterm>
<glossdef
><para
>C'est un type d'évènement qui peut être mesuré par un outil. Cela nécessite l'existence d'un capteur pour le type d'évènement donné.</para
></glossdef>
</glossentry>

<glossentry id="trace">
<glossterm
>Trace</glossterm>
<glossdef
><para
>C'est une séquence d'évènements horodatés qui se produisent lors du traçage d'un programme qui s'exécute. Sa taille est généralement proportionnelle linéairement au temps d'exécution du programme.</para
></glossdef>
</glossentry>

<glossentry id="tracepart">
<glossterm
>Partie de trace</glossterm>
<glosssee otherterm="profiledatapart"/>
</glossentry>

<glossentry id="tracing">
<glossterm
>Traçage</glossterm>
<glossdef
><para
>C'est le processus de supervision d'une exécution de programme, et de sauvegarde de ses évènements, triés par date dans un fichier de sortie, la trace.</para
></glossdef>
</glossentry>

</glossary>

<chapter id="credits">

<title
>Remerciements et licence</title>

<para
>Merci à Julian Seward pour son excellent outil &valgrind;, et à Nicholas Nethercote pour le module externe &cachegrind;. Sans ces programmes, &kcachegrind; n'aurait jamais existé. Ils sont par ailleurs à l'origine de beaucoup d'idées pour cette &GUI;. </para>
<para
>Et merci pour tous les rapports de bogues et les suggestions des différents utilisateurs. </para>

<para
>Traduction française par &YannVerley;, &LudovicGrossard;, &DamienRaudeMorvan; et &JosephRichard;.</para
> 
&underFDL; </chapter>

<appendix id="installation">
<title
>Installation</title>

<sect1 id="getting-kcachegrind">
<title
>Comment obtenir &kcachegrind;</title>

<para
>&kcachegrind; fait partie du paquetage &package; de &kde;. Pour des versions intermédiaires avec moins d'éléments gérés, &callgrind; et une documentation plus complète, allez voir le site sur <ulink url="http://kcachegrind.sf.net"
> La page internet</ulink
>. Vous pourrez aussi y voir des instructions de compilation et d'installation plus complètes. </para>
</sect1>

<sect1 id="requirements">
<title
>Prérequis</title>

<para
>Pour utiliser dans de bonnes conditions &kcachegrind;, vous avez besoin de &kde; 4.x. Pour générer les données de profilage, &cachegrind; ou &calltree; / &callgrind; sont recommandés. </para>
</sect1>

<sect1 id="compilation">
<title
>Compilation et Installation</title>
&install.compile.documentation; </sect1>

<sect1 id="configuration">
<title
>Configuration</title>

<para
>Toutes les options de configuration sont soit dans la boîte de dialogue de configuration, soit dans les menus contextuels des vues.</para>

</sect1>

</appendix>

&documentation.index;
</book>