Erreurs dans « kcachegrind.po »
Le 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ès
Fautes d'orthographe :
Message n°5,
Original : | <firstname>Federico</firstname> <surname>Zenith</surname> |
---|---|
Traduction : | <firstname>Federico</firstname> <surname>Zenith</surname> |
À la ligne 58
Rapporter un faux positif
Suggestions :
- « Frederic »
- « Frédéric »
- « Frederick »
- « Médéric »
- « Fédériez »
Message n°5,
Original : | <firstname>Federico</firstname> <surname>Zenith</surname> |
---|---|
Traduction : | <firstname>Federico</firstname> <surname>Zenith</surname> |
À la ligne 58
Rapporter un faux positif
Suggestions :
- « Zénith »
- « Zéniths »
- « Bénit »
- « Bénît »
- « Bénits »
Message n°10,
Original : | Federico Zenith |
---|---|
Traduction : | Federico Zenith |
À la ligne 93
Rapporter un faux positif
Suggestions :
- « Frederic »
- « Frédéric »
- « Frederick »
- « Médéric »
- « Fédériez »
Message n°10,
Original : | Federico Zenith |
---|---|
Traduction : | Federico Zenith |
À la ligne 93
Rapporter un faux positif
Suggestions :
- « Zénith »
- « Zéniths »
- « Bénit »
- « Bénît »
- « Bénits »
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 :
- « l'incrémentant »
- « n'incrémentant »
- « incrémentant »
- « l'incrémentât »
- « n'incrémentât »
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. |
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 :
- « Shampoing »
- « Shampoings »
- « Camping »
- « Zapping »
- « Salin »
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 »
- « Évents »
- « Éventa »
- « Évente »
- « Éventé »
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. |
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 :
- « Shampoing »
- « Shampoings »
- « Camping »
- « Zapping »
- « Salin »
Message n°29,
Original : | Another measurement method is to simulate things happening in the computer system when executing a given code, &ie; execution driven simulation. The simulation is always derived from a more or less accurate machine model; however, with very detailed machine models, giving very close approximations to reality, the simulation time can be unacceptably high in practice. The advantage of simulation is that arbitrarily complex measurement/simulation code can be inserted in a given code without perturbing results. Doing this directly before execution (called runtime instrumentation), using the original binary, is very comfortable for the user: no re-compilation is necessary. Simulation becomes usable when simulating only parts of a machine with a simple model; another advantage is that the results produced by simple models are often easier to understand: often, the problem with real hardware is that results include overlapping effects from different parts of the machine. |
---|---|
Traduction : | 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. |
À la ligne 226
Rapporter un faux positif
Suggestions :
- « re compilation »
- « re-compilation »
- « recompilassions »
- « compilation »
- « compilations »
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°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. |
À la ligne 240
Rapporter un faux positif
Suggestions :
- « re compilation »
- « re-compilation »
- « recompilassions »
- « compilation »
- « compilations »
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). |
À la ligne 247
Rapporter un faux positif
Suggestions :
- « ADAPTER »
- « ADAPTONS »
- « ADAPTE »
- « ADAPTÉ »
- « ADAPTERA »
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). |
À la ligne 247
Rapporter un faux positif
Suggestions :
- « Dyna Prof »
- « Dyna-Prof »
- « Diaprons »
- « Démembrons »
- « Timbrons »
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). |
À la ligne 247
Rapporter un faux positif
Suggestions :
- « Dominât »
- « Déminât »
- « Diminuât »
- « Dominait »
- « Dominant »
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;. |
À la ligne 366
Rapporter un faux positif
Suggestions :
- « Callgrind »
- « valgrind »
- « Hellgrind »
- « Helgrind »
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;. |
À la ligne 366
Rapporter un faux positif
Suggestions :
- « Callgrind »
- « valgrind »
- « Hellgrind »
- « Helgrind »
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>. |
À la ligne 383
Rapporter un faux positif
Suggestions :
- « Callgrind »
- « valgrind »
- « Hellgrind »
- « Helgrind »
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;. |
À la ligne 414
Rapporter un faux positif
Suggestions :
- « Control »
- « KControl »
- « DMCONTROL »
- « camcontrol »
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 :
- « Control »
- « KControl »
- « DMCONTROL »
- « camcontrol »
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 :
- « Control »
- « KControl »
- « DMCONTROL »
- « camcontrol »
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 »
- « profilé »
- « profiler »
- « profiles »
- « profilés »
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 :
- « Sample »
- « amples »
- « semples »
- « sables »
- « sablés »
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 »
- « report »
- « reports »
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 :
- « Callgrind »
- « valgrind »
- « Hellgrind »
- « Helgrind »
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. |
À la ligne 501
Rapporter un faux positif
Suggestions :
- « FunctionF »
- « Fonction »
- « Fonctions »
- « Fiction »
- « Faction »
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°132,
Original : | The name of profile data files usually ends in <literal role="extension">.<replaceable>pid</replaceable>.<replaceable>part</replaceable>-<replaceable>threadID</replaceable></literal>, where <replaceable>part</replaceable> and <replaceable>threadID</replaceable> are optional. <replaceable>pid</replaceable> and <replaceable>part</replaceable> are used for multiple profile data files belonging to one application run. By loading a file ending only in <literal role="extension"><replaceable>pid</replaceable></literal>, any existing data files for this run with additional endings are loaded as well. |
---|---|
Traduction : | 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. |
À la ligne 1151
Rapporter un faux positif
Suggestions :
- « thread ID »
- « thread-ID »
- « threads »
- « thread »
- « readcd »
Message n°132,
Original : | The name of profile data files usually ends in <literal role="extension">.<replaceable>pid</replaceable>.<replaceable>part</replaceable>-<replaceable>threadID</replaceable></literal>, where <replaceable>part</replaceable> and <replaceable>threadID</replaceable> are optional. <replaceable>pid</replaceable> and <replaceable>part</replaceable> are used for multiple profile data files belonging to one application run. By loading a file ending only in <literal role="extension"><replaceable>pid</replaceable></literal>, any existing data files for this run with additional endings are loaded as well. |
---|---|
Traduction : | 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. |
À la ligne 1151
Rapporter un faux positif
Suggestions :
- « thread ID »
- « thread-ID »
- « threads »
- « thread »
- « readcd »
Message n°149,
Original : | An abstract item related to source code to which event counts can be attributed. Dimensions for cost entities are code location (⪚ source line, function), data location (⪚ accessed data type, data object), execution location (⪚ thread, process), and tuples or triples of the aforementioned positions (⪚ calls, object access from statement, evicted data from cache). |
---|---|
Traduction : | C'est un élément abstrait relié au code source, auquel on peut attribuer des compteurs d'évènements. Les dimensions des entités de coût sont la localisation dans le code (&pex;, ligne source, fonction), la localisation dans les données (&pex;, type de la donnée accédée, donnée), la localisation dans 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). |
À la ligne 1270
Rapporter un faux positif
Suggestions :
- « triolets »
- « triples »
- « triplés »
- « triplées »
- « triplettes »
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;. |
À la ligne 1445
Rapporter un faux positif
Suggestions :
- « Steward »
- « Stewards »
- « Edward »
- « Dewar »
- « Ward »
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;. |
À la ligne 1445
Rapporter un faux positif
Suggestions :
- « Reterçâtes »
- « Meerkötter »
- « N'exerçâtes »
- « M'exerçâtes »
Dernière vérification : Sun Apr 21 21:25:33 2024 (actualisée une fois par semaine).