KDE en français
Erreurs dans « kcachegrind.po »
Corriger le fichier kcachegrind.poLe fichier kcachegrind.po comporte :
Violation de règles de traduction :
Message n°65,
| Original : | The cost entities known to &kcachegrind; are given in the following. Simple Positions: <variablelist> <varlistentry> <term>Instruction</term> <listitem><para> An assembler instruction at a specified address. </para></listitem> </varlistentry> <varlistentry> <term>Source Line of a Function</term> <listitem><para> All instructions that the compiler (via debug information) maps to a given source line specified by source file name and line number, and which are executed in the context of some function. The latter is needed because a source line inside of an inlined function can appear in the context of multiple functions. Instructions without any mapping to an actual source line are mapped to line number 0 in file <filename>???</filename>. </para></listitem> </varlistentry> <varlistentry> <term>Function</term> <listitem><para> All source lines of a given function make up the function itself. A function is specified by its name and its location in some binary object if available. The latter is needed because binary objects of a single program each can hold functions with the same name (these can be accessed ⪚ with <function>dlopen</function> or <function>dlsym</function>; the runtime linker resolves functions in a given search order of binary objects used). If a profiling tool cannot detect the symbol name of a function, ⪚ because debug information is not available, either the address of the first executed instruction typically is used, or <function>???</function>. </para></listitem> </varlistentry> <varlistentry> <term>Binary Object</term> <listitem><para> All functions whose code is inside the range of a given binary object, either the main executable or a shared library. </para></listitem> </varlistentry> <varlistentry> <term>Source File</term> <listitem><para> All functions whose first instruction is mapped to a line of the given source file. </para></listitem> </varlistentry> <varlistentry> <term>Class</term> <listitem><para> Symbol names of functions typically are hierarchically ordered in name spaces, ⪚ C++ namespaces, or classes of object-oriented languages; thus, a class can hold functions of the class or embedded classes itself. </para></listitem> </varlistentry> <varlistentry> <term>Profile Part</term> <listitem><para> Some time section of a profile run, with a given thread ID, process ID, and command line executed. </para></listitem> </varlistentry> </variablelist> As can be seen from the list, a set of cost entities often defines another cost entity; thus, there is a inclusion hierarchy of cost entities. |
|---|---|
| Traduction : | 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 dans le 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>Function</term> <listitem><para> Fonction. 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 quelques objets binaires. La dernière est nécessaire parce que les objets binaires d'un seul programme peut 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é dans les 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, ou bien 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 nommage, &pex; les espaces de nommage 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> Quelques sections de temps d'une exécution de profilage, avec un identifiant de thread donné, un identifiant de processus, et la ligne de commande exécutée. </para></listitem> </varlistentry> </variablelist> Comme on peut le voir depuis 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 qui semble évidente par rapport à la description faite au-dessus. |
Mettre une espace insécable avant et une espace aprèsFautes d'orthographe :
Message n°5,
| Original : | <firstname>Federico</firstname> <surname>Zenith</surname> |
|---|---|
| Traduction : | <firstname>Federico</firstname> <surname>Zenith</surname> |
Message n°10,
| Original : | Federico Zenith |
|---|---|
| Traduction : | Federico Zenith |
Message n°28,
| Original : | Exact measurement is possible because of hardware counters (including counters incrementing on a time tick) provided in modern processors, which are incremented whenever an event is happening. As we want to attribute events to code regions, without the counters, we would have to handle every event by incrementing a counter for the current code region ourself. Doing this in software is, of course, not possible; but, on the assumption that the event distribution over source code is similar when looking only at every n-th event instead of every event, a measurement method whose overhead is tunable has been developed: it is called Sampling. Time Based Sampling (&TBS;) uses a timer to regularly look at the program counter to create a histogram over the program code. Event Based Sampling (&EBS;) exploits the hardware counters of modern processors, and uses a mode where an interrupt handler is called on counter underflow to generate a histogram of the corresponding event distribution: in the handler, the event counter is always reinitialized to the <symbol>n</symbol> of the sampling method. The advantage of sampling is that the code does not have to be changed, but it is still a compromise: the above assumption will be more correct if <symbol>n</symbol> is small, but the smaller the <symbol>n</symbol>, the higher the overhead of the interrupt handler. |
|---|---|
| Traduction : | 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. C'est ce que l'on appelle l'échantillonnage. L'échantillonnage à base de temps (NdT : <foreignphrase>Time Based Sampling</foreignphrase> 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 : <foreignphrase>Event Based Sampling</foreignphrase> ou &EBS;) se sert des 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. |
À la ligne 219
Rapporter un faux positif
Suggestions :
- « Base »
- « BaseT »
- « Base d »
- « Bades »
- « Bases »
Message n°28,
| Original : | Exact measurement is possible because of hardware counters (including counters incrementing on a time tick) provided in modern processors, which are incremented whenever an event is happening. As we want to attribute events to code regions, without the counters, we would have to handle every event by incrementing a counter for the current code region ourself. Doing this in software is, of course, not possible; but, on the assumption that the event distribution over source code is similar when looking only at every n-th event instead of every event, a measurement method whose overhead is tunable has been developed: it is called Sampling. Time Based Sampling (&TBS;) uses a timer to regularly look at the program counter to create a histogram over the program code. Event Based Sampling (&EBS;) exploits the hardware counters of modern processors, and uses a mode where an interrupt handler is called on counter underflow to generate a histogram of the corresponding event distribution: in the handler, the event counter is always reinitialized to the <symbol>n</symbol> of the sampling method. The advantage of sampling is that the code does not have to be changed, but it is still a compromise: the above assumption will be more correct if <symbol>n</symbol> is small, but the smaller the <symbol>n</symbol>, the higher the overhead of the interrupt handler. |
|---|---|
| Traduction : | 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. C'est ce que l'on appelle l'échantillonnage. L'échantillonnage à base de temps (NdT : <foreignphrase>Time Based Sampling</foreignphrase> 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 : <foreignphrase>Event Based Sampling</foreignphrase> ou &EBS;) se sert des 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. |
À la ligne 219
Rapporter un faux positif
Suggestions :
- « Évent »
- « Vent »
- « Avent »
- « Eve nt »
- « Eve-nt »
Message n°28,
| Original : | Exact measurement is possible because of hardware counters (including counters incrementing on a time tick) provided in modern processors, which are incremented whenever an event is happening. As we want to attribute events to code regions, without the counters, we would have to handle every event by incrementing a counter for the current code region ourself. Doing this in software is, of course, not possible; but, on the assumption that the event distribution over source code is similar when looking only at every n-th event instead of every event, a measurement method whose overhead is tunable has been developed: it is called Sampling. Time Based Sampling (&TBS;) uses a timer to regularly look at the program counter to create a histogram over the program code. Event Based Sampling (&EBS;) exploits the hardware counters of modern processors, and uses a mode where an interrupt handler is called on counter underflow to generate a histogram of the corresponding event distribution: in the handler, the event counter is always reinitialized to the <symbol>n</symbol> of the sampling method. The advantage of sampling is that the code does not have to be changed, but it is still a compromise: the above assumption will be more correct if <symbol>n</symbol> is small, but the smaller the <symbol>n</symbol>, the higher the overhead of the interrupt handler. |
|---|---|
| Traduction : | 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. C'est ce que l'on appelle l'échantillonnage. L'échantillonnage à base de temps (NdT : <foreignphrase>Time Based Sampling</foreignphrase> 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 : <foreignphrase>Event Based Sampling</foreignphrase> ou &EBS;) se sert des 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. |
À la ligne 219
Rapporter un faux positif
Suggestions :
- « Base »
- « BaseT »
- « Base d »
- « Bades »
- « Bases »
Message n°31,
| Original : | Most known is the GCC profiling tool <application>gprof</application>: one needs to compile the program with option <option>-pg</option>; running the program generates a file <filename>gmon.out</filename>, which can be transformed into human-readable form with <command>gprof</command>. One disadvantage is the required re-compilation step to prepare the executable, which has to be statically linked. The method used here is compiler-generated instrumentation, which measures call arcs happening among functions and corresponding call counts, in conjunction with &TBS;, which gives a histogram of time distribution over the code. Using both pieces of information, it is possible to heuristically calculate inclusive time of functions, &ie; time spent in a function together with all functions called from it. |
|---|---|
| Traduction : | 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>, que l'utilisateur peut lire 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 qu'elle a appelées. |
Message n°31,
| Original : | Most known is the GCC profiling tool <application>gprof</application>: one needs to compile the program with option <option>-pg</option>; running the program generates a file <filename>gmon.out</filename>, which can be transformed into human-readable form with <command>gprof</command>. One disadvantage is the required re-compilation step to prepare the executable, which has to be statically linked. The method used here is compiler-generated instrumentation, which measures call arcs happening among functions and corresponding call counts, in conjunction with &TBS;, which gives a histogram of time distribution over the code. Using both pieces of information, it is possible to heuristically calculate inclusive time of functions, &ie; time spent in a function together with all functions called from it. |
|---|---|
| Traduction : | 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>, que l'utilisateur peut lire 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 qu'elle a appelées. |
Message n°32,
| Original : | For exact measurement of events happening, libraries exist with functions able to read out hardware performance counters. Most known here is the PerfCtr patch for &Linux;, and the architecture independent libraries PAPI and PCL. Still, exact measurement needs instrumentation of code, as stated above. Either one uses the libraries itself or uses automatic instrumentation systems like ADAPTOR (for FORTRAN source instrumentation) or DynaProf (code injection via DynInst). |
|---|---|
| Traduction : | 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). |
Message n°32,
| Original : | For exact measurement of events happening, libraries exist with functions able to read out hardware performance counters. Most known here is the PerfCtr patch for &Linux;, and the architecture independent libraries PAPI and PCL. Still, exact measurement needs instrumentation of code, as stated above. Either one uses the libraries itself or uses automatic instrumentation systems like ADAPTOR (for FORTRAN source instrumentation) or DynaProf (code injection via DynInst). |
|---|---|
| Traduction : | 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). |
Message n°32,
| Original : | For exact measurement of events happening, libraries exist with functions able to read out hardware performance counters. Most known here is the PerfCtr patch for &Linux;, and the architecture independent libraries PAPI and PCL. Still, exact measurement needs instrumentation of code, as stated above. Either one uses the libraries itself or uses automatic instrumentation systems like ADAPTOR (for FORTRAN source instrumentation) or DynaProf (code injection via DynInst). |
|---|---|
| Traduction : | 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). |
Message n°49,
| Original : | The most common use is to prefix the command line to start your application with <userinput><command>valgrind</command> <option>--tool=callgrind</option> </userinput>, as in: <blockquote><para><userinput> <command>valgrind</command> <option>--tool=callgrind</option> <replaceable>myprogram</replaceable> <replaceable>myargs</replaceable> </userinput></para></blockquote> At program termination, a file <filename>callgrind.out.<replaceable>pid</replaceable></filename> will be generated, which can be loaded into &kcachegrind;. |
|---|---|
| Traduction : | L'usage le plus répandu est de démarrer votre application en préfixant la ligne de commande par <userinput><command>valgrind</command> <option>--tool=callgrind</option> </userinput>, comme dans : <blockquote><para><userinput> <command>valgrind</command> <option>--tool=callgrind</option> <replaceable>mon-programme</replaceable> <replaceable>mes-arguments</replaceable> </userinput></para></blockquote> À la fin de l'exécution du programme, un fichier <filename>callgrind.out.<replaceable>pid</replaceable></filename> sera généré. il peut être chargé dans &kcachegrind;. |
Message n°49,
| Original : | The most common use is to prefix the command line to start your application with <userinput><command>valgrind</command> <option>--tool=callgrind</option> </userinput>, as in: <blockquote><para><userinput> <command>valgrind</command> <option>--tool=callgrind</option> <replaceable>myprogram</replaceable> <replaceable>myargs</replaceable> </userinput></para></blockquote> At program termination, a file <filename>callgrind.out.<replaceable>pid</replaceable></filename> will be generated, which can be loaded into &kcachegrind;. |
|---|---|
| Traduction : | L'usage le plus répandu est de démarrer votre application en préfixant la ligne de commande par <userinput><command>valgrind</command> <option>--tool=callgrind</option> </userinput>, comme dans : <blockquote><para><userinput> <command>valgrind</command> <option>--tool=callgrind</option> <replaceable>mon-programme</replaceable> <replaceable>mes-arguments</replaceable> </userinput></para></blockquote> À la fin de l'exécution du programme, un fichier <filename>callgrind.out.<replaceable>pid</replaceable></filename> sera généré. il peut être chargé dans &kcachegrind;. |
Message n°50,
| Original : | More advanced use is to dump out profile data whenever a given function of your application is called. E.g. for &konqueror;, to see profile data only for the rendering of a Web page, you could decide to dump the data whenever you select the menu item <menuchoice><guimenu>View</guimenu><guimenuitem>Reload </guimenuitem></menuchoice>. This corresponds to a call to <methodname>KonqMainWindow::slotReload</methodname>. Use: <blockquote><para><userinput> <command>valgrind</command> <option>--tool=callgrind</option> <option>--dump-before=KonqMainWindow::slotReload</option> <replaceable>konqueror</replaceable> </userinput></para></blockquote> This will produce multiple profile data files with an additional sequential number at the end of the filename. A file without such an number at the end (only ending in the process PID) will also be produced; by loading this file into &kcachegrind;, all others are loaded too, and can be seen in the <guilabel>Parts Overview</guilabel> and <guilabel>Parts</guilabel> list. |
|---|---|
| Traduction : | 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 n'avoir 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> et dans la <guilabel>liste des parties</guilabel>. |
Message n°50,
| Original : | More advanced use is to dump out profile data whenever a given function of your application is called. E.g. for &konqueror;, to see profile data only for the rendering of a Web page, you could decide to dump the data whenever you select the menu item <menuchoice><guimenu>View</guimenu><guimenuitem>Reload </guimenuitem></menuchoice>. This corresponds to a call to <methodname>KonqMainWindow::slotReload</methodname>. Use: <blockquote><para><userinput> <command>valgrind</command> <option>--tool=callgrind</option> <option>--dump-before=KonqMainWindow::slotReload</option> <replaceable>konqueror</replaceable> </userinput></para></blockquote> This will produce multiple profile data files with an additional sequential number at the end of the filename. A file without such an number at the end (only ending in the process PID) will also be produced; by loading this file into &kcachegrind;, all others are loaded too, and can be seen in the <guilabel>Parts Overview</guilabel> and <guilabel>Parts</guilabel> list. |
|---|---|
| Traduction : | 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 n'avoir 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> et dans la <guilabel>liste des parties</guilabel>. |
Message n°50,
| Original : | More advanced use is to dump out profile data whenever a given function of your application is called. E.g. for &konqueror;, to see profile data only for the rendering of a Web page, you could decide to dump the data whenever you select the menu item <menuchoice><guimenu>View</guimenu><guimenuitem>Reload </guimenuitem></menuchoice>. This corresponds to a call to <methodname>KonqMainWindow::slotReload</methodname>. Use: <blockquote><para><userinput> <command>valgrind</command> <option>--tool=callgrind</option> <option>--dump-before=KonqMainWindow::slotReload</option> <replaceable>konqueror</replaceable> </userinput></para></blockquote> This will produce multiple profile data files with an additional sequential number at the end of the filename. A file without such an number at the end (only ending in the process PID) will also be produced; by loading this file into &kcachegrind;, all others are loaded too, and can be seen in the <guilabel>Parts Overview</guilabel> and <guilabel>Parts</guilabel> list. |
|---|---|
| Traduction : | 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 n'avoir 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> et dans la <guilabel>liste des parties</guilabel>. |
Message n°53,
| Original : | System-wide profiling is only permitted to the root user, as all actions on the system can be observed; therefore, the following has to be done as root. First, configure the profiling process, using the &GUI; <command>oprof_start</command> or the command-line tool <command>opcontrol</command>. Standard configuration should be timer mode (&TBS;, see introduction). To start the measurement, run <userinput><command>opcontrol</command> <option>-s</option></userinput>. Then run the application you are interested in and, afterwards, do a <userinput><command>opcontrol</command> <option>-d</option></userinput>. This will write out the measurement results into files under folder <filename class="directory">/var/lib/oprofile/samples/</filename>. To be able to visualize the data in &kcachegrind;, do in an empty directory: <blockquote><para><userinput> <command>opreport</command> <option>-gdf</option> | <command>op2callgrind</command> </userinput></para></blockquote> This will produce a lot of files, one for every program which was running on the system. Each one can be loaded into &kcachegrind; on its own. |
|---|---|
| Traduction : | 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 l'interface graphique avec <command>oprof_start</command> ou l'outil en ligne de commande <command>opcontrol</command>. Une configuration standard devrait être le mode temps (&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 sous 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;. |
Message n°53,
| Original : | System-wide profiling is only permitted to the root user, as all actions on the system can be observed; therefore, the following has to be done as root. First, configure the profiling process, using the &GUI; <command>oprof_start</command> or the command-line tool <command>opcontrol</command>. Standard configuration should be timer mode (&TBS;, see introduction). To start the measurement, run <userinput><command>opcontrol</command> <option>-s</option></userinput>. Then run the application you are interested in and, afterwards, do a <userinput><command>opcontrol</command> <option>-d</option></userinput>. This will write out the measurement results into files under folder <filename class="directory">/var/lib/oprofile/samples/</filename>. To be able to visualize the data in &kcachegrind;, do in an empty directory: <blockquote><para><userinput> <command>opreport</command> <option>-gdf</option> | <command>op2callgrind</command> </userinput></para></blockquote> This will produce a lot of files, one for every program which was running on the system. Each one can be loaded into &kcachegrind; on its own. |
|---|---|
| Traduction : | 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 l'interface graphique avec <command>oprof_start</command> ou l'outil en ligne de commande <command>opcontrol</command>. Une configuration standard devrait être le mode temps (&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 sous 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;. |
Message n°53,
| Original : | System-wide profiling is only permitted to the root user, as all actions on the system can be observed; therefore, the following has to be done as root. First, configure the profiling process, using the &GUI; <command>oprof_start</command> or the command-line tool <command>opcontrol</command>. Standard configuration should be timer mode (&TBS;, see introduction). To start the measurement, run <userinput><command>opcontrol</command> <option>-s</option></userinput>. Then run the application you are interested in and, afterwards, do a <userinput><command>opcontrol</command> <option>-d</option></userinput>. This will write out the measurement results into files under folder <filename class="directory">/var/lib/oprofile/samples/</filename>. To be able to visualize the data in &kcachegrind;, do in an empty directory: <blockquote><para><userinput> <command>opreport</command> <option>-gdf</option> | <command>op2callgrind</command> </userinput></para></blockquote> This will produce a lot of files, one for every program which was running on the system. Each one can be loaded into &kcachegrind; on its own. |
|---|---|
| Traduction : | 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 l'interface graphique avec <command>oprof_start</command> ou l'outil en ligne de commande <command>opcontrol</command>. Une configuration standard devrait être le mode temps (&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 sous 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;. |
Message n°53,
| Original : | System-wide profiling is only permitted to the root user, as all actions on the system can be observed; therefore, the following has to be done as root. First, configure the profiling process, using the &GUI; <command>oprof_start</command> or the command-line tool <command>opcontrol</command>. Standard configuration should be timer mode (&TBS;, see introduction). To start the measurement, run <userinput><command>opcontrol</command> <option>-s</option></userinput>. Then run the application you are interested in and, afterwards, do a <userinput><command>opcontrol</command> <option>-d</option></userinput>. This will write out the measurement results into files under folder <filename class="directory">/var/lib/oprofile/samples/</filename>. To be able to visualize the data in &kcachegrind;, do in an empty directory: <blockquote><para><userinput> <command>opreport</command> <option>-gdf</option> | <command>op2callgrind</command> </userinput></para></blockquote> This will produce a lot of files, one for every program which was running on the system. Each one can be loaded into &kcachegrind; on its own. |
|---|---|
| Traduction : | 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 l'interface graphique avec <command>oprof_start</command> ou l'outil en ligne de commande <command>opcontrol</command>. Une configuration standard devrait être le mode temps (&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 sous 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;. |
Message n°53,
| Original : | System-wide profiling is only permitted to the root user, as all actions on the system can be observed; therefore, the following has to be done as root. First, configure the profiling process, using the &GUI; <command>oprof_start</command> or the command-line tool <command>opcontrol</command>. Standard configuration should be timer mode (&TBS;, see introduction). To start the measurement, run <userinput><command>opcontrol</command> <option>-s</option></userinput>. Then run the application you are interested in and, afterwards, do a <userinput><command>opcontrol</command> <option>-d</option></userinput>. This will write out the measurement results into files under folder <filename class="directory">/var/lib/oprofile/samples/</filename>. To be able to visualize the data in &kcachegrind;, do in an empty directory: <blockquote><para><userinput> <command>opreport</command> <option>-gdf</option> | <command>op2callgrind</command> </userinput></para></blockquote> This will produce a lot of files, one for every program which was running on the system. Each one can be loaded into &kcachegrind; on its own. |
|---|---|
| Traduction : | 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 l'interface graphique avec <command>oprof_start</command> ou l'outil en ligne de commande <command>opcontrol</command>. Une configuration standard devrait être le mode temps (&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 sous 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;. |
Message n°53,
| Original : | System-wide profiling is only permitted to the root user, as all actions on the system can be observed; therefore, the following has to be done as root. First, configure the profiling process, using the &GUI; <command>oprof_start</command> or the command-line tool <command>opcontrol</command>. Standard configuration should be timer mode (&TBS;, see introduction). To start the measurement, run <userinput><command>opcontrol</command> <option>-s</option></userinput>. Then run the application you are interested in and, afterwards, do a <userinput><command>opcontrol</command> <option>-d</option></userinput>. This will write out the measurement results into files under folder <filename class="directory">/var/lib/oprofile/samples/</filename>. To be able to visualize the data in &kcachegrind;, do in an empty directory: <blockquote><para><userinput> <command>opreport</command> <option>-gdf</option> | <command>op2callgrind</command> </userinput></para></blockquote> This will produce a lot of files, one for every program which was running on the system. Each one can be loaded into &kcachegrind; on its own. |
|---|---|
| Traduction : | 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 l'interface graphique avec <command>oprof_start</command> ou l'outil en ligne de commande <command>opcontrol</command>. Une configuration standard devrait être le mode temps (&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 sous 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;. |
À la ligne 414
Rapporter un faux positif
Suggestions :
- « profile »
- « o profile »
- « openProfile »
- « profiterole »
- « profil »
Message n°53,
| Original : | System-wide profiling is only permitted to the root user, as all actions on the system can be observed; therefore, the following has to be done as root. First, configure the profiling process, using the &GUI; <command>oprof_start</command> or the command-line tool <command>opcontrol</command>. Standard configuration should be timer mode (&TBS;, see introduction). To start the measurement, run <userinput><command>opcontrol</command> <option>-s</option></userinput>. Then run the application you are interested in and, afterwards, do a <userinput><command>opcontrol</command> <option>-d</option></userinput>. This will write out the measurement results into files under folder <filename class="directory">/var/lib/oprofile/samples/</filename>. To be able to visualize the data in &kcachegrind;, do in an empty directory: <blockquote><para><userinput> <command>opreport</command> <option>-gdf</option> | <command>op2callgrind</command> </userinput></para></blockquote> This will produce a lot of files, one for every program which was running on the system. Each one can be loaded into &kcachegrind; on its own. |
|---|---|
| Traduction : | 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 l'interface graphique avec <command>oprof_start</command> ou l'outil en ligne de commande <command>opcontrol</command>. Une configuration standard devrait être le mode temps (&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 sous 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;. |
À la ligne 414
Rapporter un faux positif
Suggestions :
- « op report »
- « op-report »
- « KoReport »
- « reporter »
- « report »
Message n°53,
| Original : | System-wide profiling is only permitted to the root user, as all actions on the system can be observed; therefore, the following has to be done as root. First, configure the profiling process, using the &GUI; <command>oprof_start</command> or the command-line tool <command>opcontrol</command>. Standard configuration should be timer mode (&TBS;, see introduction). To start the measurement, run <userinput><command>opcontrol</command> <option>-s</option></userinput>. Then run the application you are interested in and, afterwards, do a <userinput><command>opcontrol</command> <option>-d</option></userinput>. This will write out the measurement results into files under folder <filename class="directory">/var/lib/oprofile/samples/</filename>. To be able to visualize the data in &kcachegrind;, do in an empty directory: <blockquote><para><userinput> <command>opreport</command> <option>-gdf</option> | <command>op2callgrind</command> </userinput></para></blockquote> This will produce a lot of files, one for every program which was running on the system. Each one can be loaded into &kcachegrind; on its own. |
|---|---|
| Traduction : | 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 l'interface graphique avec <command>oprof_start</command> ou l'outil en ligne de commande <command>opcontrol</command>. Une configuration standard devrait être le mode temps (&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 sous 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;. |
Message n°64,
| Original : | The cost entities known to &kcachegrind; are given in the following. Simple Positions: <variablelist> <varlistentry> <term>Instruction</term> <listitem><para> An assembler instruction at a specified address. </para></listitem> </varlistentry> <varlistentry> <term>Source Line of a Function</term> <listitem><para> All instructions that the compiler (via debug information) maps to a given source line specified by source file name and line number, and which are executed in the context of some function. The latter is needed because a source line inside of an inlined function can appear in the context of multiple functions. Instructions without any mapping to an actual source line are mapped to line number 0 in file <filename>???</filename>. </para></listitem> </varlistentry> <varlistentry> <term>Function</term> <listitem><para> All source lines of a given function make up the function itself. A function is specified by its name and its location in some binary object if available. The latter is needed because binary objects of a single program each can hold functions with the same name (these can be accessed ⪚ with <function>dlopen</function> or <function>dlsym</function>; the runtime linker resolves functions in a given search order of binary objects used). If a profiling tool cannot detect the symbol name of a function, ⪚ because debug information is not available, either the address of the first executed instruction typically is used, or <function>???</function>. </para></listitem> </varlistentry> <varlistentry> <term>Binary Object</term> <listitem><para> All functions whose code is inside the range of a given binary object, either the main executable or a shared library. </para></listitem> </varlistentry> <varlistentry> <term>Source File</term> <listitem><para> All functions whose first instruction is mapped to a line of the given source file. </para></listitem> </varlistentry> <varlistentry> <term>Class</term> <listitem><para> Symbol names of functions typically are hierarchically ordered in name spaces, ⪚ C++ namespaces, or classes of object-oriented languages; thus, a class can hold functions of the class or embedded classes itself. </para></listitem> </varlistentry> <varlistentry> <term>Profile Part</term> <listitem><para> Some time section of a profile run, with a given thread ID, process ID, and command line executed. </para></listitem> </varlistentry> </variablelist> As can be seen from the list, a set of cost entities often defines another cost entity; thus, there is a inclusion hierarchy of cost entities. |
|---|---|
| Traduction : | 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 dans le 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>Function</term> <listitem><para> Fonction. 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 quelques objets binaires. La dernière est nécessaire parce que les objets binaires d'un seul programme peut 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é dans les 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, ou bien 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 nommage, &pex; les espaces de nommage 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> Quelques sections de temps d'une exécution de profilage, avec un identifiant de thread donné, un identifiant de processus, et la ligne de commande exécutée. </para></listitem> </varlistentry> </variablelist> Comme on peut le voir depuis 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 qui semble évidente par rapport à la description faite au-dessus. |
Message n°64,
| Original : | The cost entities known to &kcachegrind; are given in the following. Simple Positions: <variablelist> <varlistentry> <term>Instruction</term> <listitem><para> An assembler instruction at a specified address. </para></listitem> </varlistentry> <varlistentry> <term>Source Line of a Function</term> <listitem><para> All instructions that the compiler (via debug information) maps to a given source line specified by source file name and line number, and which are executed in the context of some function. The latter is needed because a source line inside of an inlined function can appear in the context of multiple functions. Instructions without any mapping to an actual source line are mapped to line number 0 in file <filename>???</filename>. </para></listitem> </varlistentry> <varlistentry> <term>Function</term> <listitem><para> All source lines of a given function make up the function itself. A function is specified by its name and its location in some binary object if available. The latter is needed because binary objects of a single program each can hold functions with the same name (these can be accessed ⪚ with <function>dlopen</function> or <function>dlsym</function>; the runtime linker resolves functions in a given search order of binary objects used). If a profiling tool cannot detect the symbol name of a function, ⪚ because debug information is not available, either the address of the first executed instruction typically is used, or <function>???</function>. </para></listitem> </varlistentry> <varlistentry> <term>Binary Object</term> <listitem><para> All functions whose code is inside the range of a given binary object, either the main executable or a shared library. </para></listitem> </varlistentry> <varlistentry> <term>Source File</term> <listitem><para> All functions whose first instruction is mapped to a line of the given source file. </para></listitem> </varlistentry> <varlistentry> <term>Class</term> <listitem><para> Symbol names of functions typically are hierarchically ordered in name spaces, ⪚ C++ namespaces, or classes of object-oriented languages; thus, a class can hold functions of the class or embedded classes itself. </para></listitem> </varlistentry> <varlistentry> <term>Profile Part</term> <listitem><para> Some time section of a profile run, with a given thread ID, process ID, and command line executed. </para></listitem> </varlistentry> </variablelist> As can be seen from the list, a set of cost entities often defines another cost entity; thus, there is a inclusion hierarchy of cost entities. |
|---|---|
| Traduction : | 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 dans le 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>Function</term> <listitem><para> Fonction. 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 quelques objets binaires. La dernière est nécessaire parce que les objets binaires d'un seul programme peut 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é dans les 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, ou bien 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 nommage, &pex; les espaces de nommage 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> Quelques sections de temps d'une exécution de profilage, avec un identifiant de thread donné, un identifiant de processus, et la ligne de commande exécutée. </para></listitem> </varlistentry> </variablelist> Comme on peut le voir depuis 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 qui semble évidente par rapport à la description faite au-dessus. |
Message n°174,
| Original : | Thanks to Julian Seward for his excellent &valgrind;, and Nicholas Nethercote for the &cachegrind; addition. Without these programs, &kcachegrind; would not exist. Some ideas for this &GUI; were from them, too. |
|---|---|
| Traduction : | 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;. |
Message n°174,
| Original : | Thanks to Julian Seward for his excellent &valgrind;, and Nicholas Nethercote for the &cachegrind; addition. Without these programs, &kcachegrind; would not exist. Some ideas for this &GUI; were from them, too. |
|---|---|
| Traduction : | 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;. |
Dernière vérification : Tue Aug 20 12:30:48 2024 (actualisée une fois par semaine).
Retour