# Handbok &kcachegrind;

Josef
Weidendorfer

    Josef.Weidendorfer@gmx.de

Ursprunglig författare av dokumentationen
Federico
Zenith

    federico.zenith@member.fsf.org

Uppdateringar och rättningar
Stefan
Asserhäll

    stefan.asserhall@bredband.net

Översättare
2002-2004
&Josef.Weidendorfer;
2009
Federico Zenith
&FDLNotice;
2016-11-18
0.8.0 (Program 17.04)

&kcachegrind; är ett visualiseringsverktyg för profileringsdata, skrivet med användning av &kde; Ramverk.

KDE
kdesdk
Cachegrind
Callgrind
Valgrind
Profilering

## Inledning

&kcachegrind; är en bläddringsverktyg för data som producerats av profileringsverktyg. Det här kapitlet förklarar vad profilering är till för, hur den görs, och ger några exempel på tillgängliga profileringsverktyg.

### Profilering

När ett program utvecklas, omfattar ett av de sista stegen ofta prestandaoptimering. Eftersom det inte är vettigt att optimera funktioner som sällan används, vilket skulle vara bortkastad tid, måste man veta i vilka delar av programmet som den största delen av tiden går åt.

För sekvensiell kod är det ofta tillräckligt att samla statistisk data om programmets beteende under körning, som åtgången tid i funktioner och per kodrad. Det kallas profilering. Programmet körs under övervakning av ett profileringsverktyg, som ger summeringen av en programkörning vid slutet. Däremot, för parallell kod, uppstår prestandaproblem oftast när en processor väntar på data från en annan. Eftersom väntetiden oftast inte enkelt kan fördelas, är det bättre att skapa tidsstämplade händelseföljder. &kcachegrind; kan inte visualisera den sortens data.

Efter att ha analyserat skapad profileringsdata ska det vara enkelt att se utsatta ställen och flaskhalsar i koden. Till exempel kan antaganden om antal anrop kontrolleras, och identifierade kodavsnitt kan optimeras. Efteråt bör optimeringens resultat verifieras med ytterligare en profileringskörning.

### Profileringsmetoder

För att exakt mäta tiden som går eller spela in händelser som inträffar under körning av ett kodavsnitt (t.ex. en funktion) krävs att ytterligare uppmätningskod infogas innan och efter det givna området. Den här koden läser tiden eller en global händelseräknare, och beräknar skillnader. Alltså måste originalkoden ändras innan körning. Det kallas instrumentering. Instrumentering kan göras av programmeraren själv, av kompilatorn eller av körningssystemet. Eftersom intressanta områden ofta är i flera nivåer, påverkar tiden som går åt för mätningen alltid mätresultatet. Därför måste instrumentering göras selektivt och resultaten måste tolkas noggrant. Detta gör förstås prestandaanalys med exakta mätningar till en mycket komplex process.

Exakta mätningar är möjliga på grund av räknare i hårdvara (inklusive räknare som ökas när tiden tickar), som tillhandahålls i moderna processorer, och som ökas så fort en händelse inträffar. Eftersom vi vill tilldela händelser till kodavsnitt, skulle vi behöva hantera varje händelse genom att öka en räknare för det aktuella kodavsnittet själva, om inte räknarna fanns. Att göra detta i programvara är förstås inte möjligt. Men med antagandet att distributionen av händelser i källkoden är liknande om man bara tittar på var n:e händelse istället för varje, har en mätmetod som är justerbar med avseende på tiden som går åt för mätningen skapats. Den kallas sampling. Tidsbaserad sampling (TBS) använder tidmätning för att regelbundet titta på programräknaren för att skapa ett histogram av programmets kod. Händelsebaserad sampling (EBS) utnyttjar hårdvaruräknarna i moderna processorer, och använder ett läge där en avbrottshanterare anropas när en räknare går förbi nollvärdet, och skapar ett histogram av motsvarande händelsefördelning. I avbrottshanteraren initieras räknaren alltid om till n i samplingsmetoden. Fördelen med sampling är att koden inte behöver ändras, men det är fortfarande en kompromiss: antagandet ovan är riktigare om n är litet, men ju mindre n är, desto större är tiden som går åt i avbrottshanteraren.

En annan mätmetod är att simulera det som händer i ett datorsystem när en given kod körs, dvs. körningsstyrd simulering. Simuleringen härleds alltid från en mer eller mindre noggrann modell av datorn. För mycket detaljerade modeller som är nära verkligheten, kan simuleringstiden dock vara oacceptabelt hög i praktiken. Fördelen med simulering är att godtyckligt komplex mätnings- och simuleringskod kan infogas i en given kod utan att störa resultaten. Att göra detta direkt innan körningen (vilket kallas instrumentering vid körning) med det ursprungliga binärprogrammet, är mycket bekvämt för användaren: Ingen omkompilering behövs. Simulering blir användbar om bara delar av en dator simulerats med en enkel modell. En annan fördel är att resultat som skapas av enkla modeller ofta är mycket enklare att förstå: problemet med riktig hårdvara är ofta att resultaten innehåller överlappande effekter från olika delar av datorn.

### Profileringsverktyg

Mest känt är GCC:s profileringsverktyg gprof. Man måste kompilera programmet med väljaren `-pg`, köra programmet för att skapa filen `gmon.out`, som kan översättas till läsbar form med `gprof`. En nackdel är omkompileringssteget för att förbereda det körbara programmet, som också måste länkas statiskt. Metoden som används här är instrumentering skapad av kompilatorn, som mäter anrop som sker mellan funktioner och motsvarande antal anrop, tillsammans med tidsbaserad sampling, vilket ger ett histogram av tidsdistributionen i koden. Med båda typerna av information är det möjligt att heuristiskt beräkna samlad tid i funktioner, dvs. tiden som går åt i en funktion tillsammans med alla funktioner som anropas från den.

För exakt mätning av händelser som inträffar, finns det bibliotek med funktioner som kan läsa ut hårdvaruprestandaräknare. Mest välkänd är programfixen PerfCtr för &Linux;, och de arkitekturoberoende biblioteken PAPI och PCL. Exakta mätningar behöver ändå instrumentering av koden, som tidigare beskrivits. Antingen använder man biblioteken själv, eller automatiska instrumenteringssystem som ADAPTOR (för instrumentering av FORTRAN källkod) eller DynaProf (kodinjicering via DynInst).

&oprofile; är ett systemprofileringsverktyg för &Linux; som använder sampling.

I många avseenden är ett bekvämt sätt att utföra profilering att använda &cachegrind; eller &callgrind;, vilka är simulatorer som använder ramverket &valgrind; för instrumentering vid körning. Eftersom det inte finns något behov av att komma åt hårdvaruräknare (ofta svårt med dagens &Linux;-installationer), och binärprogram som ska profileras kan lämnas oförändrade, är det ett bra alternativt sätt jämfört med andra profileringsverktyg. Nackdelen med långsammare körning på grund av simuleringen kan reduceras genom att bara utföra simuleringen för intressanta programavsnitt, och kanske bara under några få iterationer av en snurra. Utan instrumentering för mätning och simulering leder &valgrind;s användning bara till en körning som är 3 till 5 gånger långsammare. Dessutom, om bara anropsdiagrammet och anropsantalen är intressanta, kan cachesimuleringen stängas av.

Cachesimulering är det första steget i att approximera realtid, eftersom i moderna system är körtiden mycket känslig för hur så kallade cacher utnyttjas (små och snabba buffrar som snabbar upp upprepade åtkomster till samma celler i huvudminnet). &cachegrind; simulerar cacher genom att lagra minnesaccesser i cacherna. Den data som skapas omfattar antal åtkomster till instruktions- och dataminnet och cachemissar i första och andra nivåns cacher, och den relateras till källkodsrader och funktioner i programmet som kör. Genom att kombinera antal missar, och använda latenstider för missar för typiska processorer, kan en uppskattning av åtgången tid ges.

&callgrind; är en utökning av &cachegrind; som bygger upp anropsträdet för ett program i farten, dvs. hur funktionerna anropar varandra och hur många händelser som inträffar när en funktion körs. Dessutom kan den profileringsdata som måste samlas in delas upp enligt trådar och anropskedjans sammanhang. Det kan tillhandahålla profileringsdata på instruktionsnivå för att göra det möjligt att kommentera disassemblerad kod.

### Visualisering

Profileringsverktyg skapar typiskt en stor mängd data. Önskan att snabbt bläddra uppåt och neråt i anropsdiagrammet, tillsammans med snabbt byte av sorteringsläge för funktioner och visning av olika händelsetyper, motiverar ett grafiskt gränssnitt för att utföra uppgiften.

&kcachegrind; är ett visualiseringsverktyg för profileringsdata som uppfyller dessa önskemål. Även om det först programmerats med bläddring i data från &cachegrind; och &calltree; i åtanke, finns det konverteringsprogram tillgängliga för att kunna visa profileringsdata som skapats av andra verktyg. I appendix ges en beskrivning av filformatet som används av &cachegrind;/&callgrind;.

Förutom en lista med funktioner sorterade enligt mätetal över enskild eller samlad kostnad, eventuellt grupperade enligt källkodsfil, delat bibliotek eller C++ klass, erbjuder &kcachegrind; diverse visualiseringsvyer för en vald funktion, närmare bestämt:

- en anropsdiagramvy, som visar en del av anropsdiagrammet omkring den valda funktionen,

- en trädkarta, som gör det möjligt att visualisera anropsförhållanden i flera nivåer tillsammans med mätetal över samlad kostnad för snabb visuell detektering av problematiska funktioner,

- vyer för källkods- och assemblerkommentarer, som gör det möjligt att se kostnadsinformation relaterat till källkodsrader och assemblerinstruktioner.

## Att använda &kcachegrind;

### Skapa data att visualisera

Först vill man skapa prestandainformation genom att mäta olika aspekter av ett programs beteende under körning, genom att använda ett profileringsverktyg. &kcachegrind; själv inkluderar inte något profileringsverktyg, men är bra på att användas tillsammans med &callgrind;, och kan också användas för att visualisera data som skapats av &oprofile;, genom att använda ett konverteringsprogram. Även om syftet med den här handboken inte är att dokumentera profilering med dessa verktyg, ger nästa avsnitt korta handledningar för att du snabbt ska komma igång.

#### &callgrind;

&callgrind; är en del av &valgrind;. Observera att det tidigare kallades &calltree; men det namnet var missvisande.

Den vanligaste användningen är att inleda kommandot för att starta ditt program med ``valgrind` `--tool=callgrind`` , som med:

> ``valgrind` `--tool=callgrind` mitt_program mina_väljare`

När programmet avslutas skapas filen `callgrind.out.pid`, som kan laddas i &kcachegrind;.

Mer avancerad användning är att lagra profileringsdata så fort en given funktion i programmet anropas. För att t.ex. bara se profileringsdata när en webbsida ritas upp i &konqueror;, skulle du kunna bestämma att lagra data så fort du väljer menyalternativet Visa Uppdatera. Det motsvarar ett anrop till `KonqMainWindow::slotReload`. Använd

> ``valgrind` `--tool=callgrind` `--dump-before=KonqMainWindow::slotReload` konqueror`

Det skapar flera profileringsdatafiler med ett ytterligare sekvensnummer i slutet på filnamnet. En fil utan ett sådant nummer (som bara slutar med process-id) skapas också. Genom att ladda den filen i &kcachegrind;, så laddas alla övriga också, och kan ses i översikten över delar och i listan med delar.

#### &oprofile;

&oprofile; är tillgänglig från dess hemsida. Följ installeringsinstruktionerna på webbplatsen, men innan du gör det kontrollera om din distribution inte redan tillhandahåller det som ett paket (som &SuSE;).

Profilering på systemnivå är bara tillåtet för systemadministratören, eftersom alla åtgärder i systemet kan observeras. Därför måste följande göras som systemadministratör. Anpassa först profileringsprocessen med det grafiska gränssnittet `oprof_start`, eller kommandoradverktyget `opcontrol`. Standardinställningen ska vara tidsläge (TBS, se inledningen). För att starta mätningen, kör ``opcontrol` `-s``. Kör därefter programmet du är intresserad av, och skriv efteråt ``opcontrol` `-d``. Det skriver ut mätresultaten i filer under katalogen `/var/lib/oprofile/samples/`. För att kunna visualisera data i &kcachegrind; gör följande i en tom katalog:

> ``opreport` `-gdf` | `op2callgrind``

Det skapar många filer, en för varje program som kördes på systemet. Var och en kan laddas i &kcachegrind; för sig.

### Grunderna i användargränssnittet

När &kcachegrind; startas med en profileringsdatafil som argument, eller efter en fil har laddats med Arkiv Öppna, ser du en sidopanel som innehåller funktionslistan till vänster, och till höger huvudområdet för visualiseringar av den valda funktionen. Visualiseringsområdet kan ställas in godtyckligt för att visa flera visualiseringar samtidigt.

Efter första start är området uppdelad i en övre och undre del, var och en med olika vyer valbara via flikar. Använd flikarnas sammanhangsberoende menyer för att flytta vyer, och justera avdelarna mellan vyer. För att snabbt byta mellan olika layouter, använd &Ctrl;→ Visa Layout Gå till nästa och &Ctrl;← Visa Layout Gå till föregående.

Den aktiva händelsetypen är viktig för visualiseringarna: för &callgrind; är det till exempel cachemissar eller cykeluppskattningar, för &oprofile; är det timer i det enklaste fallet. Du kan ändra händelsetyp via en kombinationsruta i verktygsraden eller i vyn Händelsetyp. En första översikt över beteendet under körning bör ges när du väljer funktionen `main` i listan till vänster, och tittar på visualiseringen anropsdiagram. Där ser du anropen som sker i programmet. Observera att anropsdiagramvyn bara visar funktioner med ett högt händelseantal. Genom att dubbelklicka på en funktion i diagrammet ändras det så att anropade funktioner omkring den valda visas.

För att utforska det grafiska gränssnittet ytterligare, förutom den här handboken, ta också en titt på dokumentationsavsnittet på webbsidan. Förutom detta, har varje grafisk komponent i &kcachegrind; hjälp via Vad är det här?.

## Grundläggande begrepp

Det här kapitlet förklarar några begrepp i &kcachegrind; och introducerar termer som används i gränssnittet.

### Datamodellen för profileringsdata

#### Kostnadsenheter

Kostnadsantal för händelsetyper (som L2 missar) tilldelas till kostnadsenheter, som är objekt med förhållanden till källkod eller datastrukturer i ett givet program. Kostnadsenheter kan inte bara vara enkla kod- eller datapositioner, utan också sammansatta positioner. Ett anrop kan till exempel ha en källa och ett mål, eller en dataadress kan ha en datatyp och en kodposition där data har skapats.

Kostnadsenheterna som &kcachegrind; känner till anges här. Enkla positioner:

Instruktion

  En assemblerinstruktion på en given adress.

Källkodsrad i en funktion

  Alla instruktioner som kompilatorn (via avlusningsinformation) avbildar på en given källkodsrad angiven med källkodsfilnamn och radnummer, och som körs i ett visst funktionssammanhang. Instruktioner utan en avbildning till en verklig källkodsrad använder radnummer 0 i filen `???`.

Funktion

  En given funktion består av alla källkodsrader i själva funktionen. En funktion anges av sitt namn och sin plats i ett visst binärobjekt om tillgängligt. Det senare behövs eftersom binärobjekt i ett enda program vart och ett kan innehålla funktioner med samma namn (de kan t.ex. kommas åt med `dlopen` eller `dlsym`. Länkaren löser upp funktioner i en given sökordning för binärobjekt som används vid körning). Om ett profileringsverktyg inte kan detektera en funktions symbolnamn, t.ex. på grund av att avlusningsinformation inte är tillgänglig, används typiskt antingen adressen för den första instruktionen som körs, eller `???`.

Binärobjekt

  Alla funktioner vars kod är inne i ett givet binärobjekts område, antingen i det körbara huvudprogrammet eller ett delat bibliotek.

Källkodsfil

  Alla funktioner vars första instruktion avbildas till en rad i den givna källkodsfilen.

Klass

  Symbolnamn i funktioner är ofta ordnade i hierarkiska namnrymder, t.ex. C++ namnrymder, eller klasser i objektorienterade språk. Därför kan en klass själv innehålla funktioner i klassen eller inbäddade klasser.

Profileringsdel

  Ett visst tidsavsnitt av en profileringskörning, med ett givet tråd-id, process-id och kommandorad som kördes.

Som syns i listan, definierar en uppsättning kostnadsenheter ofta en annan kostnadsenhet. Därför finns det en hierarki med ingående kostnadsenheter, som bör vara uppenbar från beskrivningen ovan.

Positionsinformation:

- Anrop från instruktionsadress till målfunktion.

- Anrop från källkodsrad till målfunktion.

- Anrop från källfunktion till målfunktion.

- (O)villkorligt hopp från käll- till målinstruktion.

- (O)villkorligt hopp från käll- till målrad.

Hopp mellan funktioner tillåts inte, eftersom det inte är vettigt i ett anropsdiagram. Därför måste konstruktioner som undantagshantering och långa hopp i C översättas genom att gå bakåt i anropsstacken efter behov.

#### Händelsetyper

Godtyckliga händelsetyper kan anges i profileringsdata genom att ge dem ett namn. Deras kostnad i förhållande till en kostnadsenhet är ett 64-bitars heltal.

Händelsetyper vars kostnad anges i en profileringsdatafil kallas verkliga händelser. Dessutom kan man ange formler för händelsetyper som beräknas från verkliga händelser, som kallas ärvda händelser.

### Visualiseringstillstånd

Visualiseringstillståndet i ett fönster i &kcachegrind; omfattar:

- den primära och sekundära händelsetypen som valts att visas,

- funktionsgrupperingen (används i listan Funktionsprofilering och enhetsfärgningen),

- profileringsdelarna vars kostnad ska ingå i visualiseringen,

- en aktiv kostnadsenhet (t.ex. en funktion som valts i sidopanelen för funktionsprofilering),

- en vald kostnadsenhet.

Tillståndet påverkar visualiseringarna.

Visualiseringar visas bara för en kostnadsenhet, den aktiva. Om en given visualisering inte är lämplig för en kostnadsenhet, inaktiveras den: om t.ex. ett &ELF;-objekt väljes i grupplistan, är inte källkodskommentarer vettiga.

För en aktiv funktion visar till exempel listan över de som blir anropade alla funktioner som anropas från den aktiva funktionen. Man kan välja en av funktionerna utan att göra den aktiv. Om anropsdiagrammet dessutom visas intill, väljes automatiskt samma funktion där.

### Delar i det grafiska gränssnittet

#### Sidopaneler

Sidopaneler är sidofönster som kan placeras vid vilken kant som helst i ett fönster i &kcachegrind;. De innehåller alltid en lista med kostnadsenheter sorterade på något sätt.

- Funktionsprofilering är en lista med funktioner som visar kostnaden som uppstår i och utanför funktionen, namn och funktionens position.

- Översikt över delar

- Anropsstack

#### Visualiseringsområdet

Visualiseringsområdet, typiskt den högra delen av ett huvudfönster i &kcachegrind;, består av en (förvalt värde) eller flera flikar, antingen uppradade horisontellt eller vertikalt. Varje flik innehåller olika visualiseringar av en enda kostnadsenhet åt gången. Namnet på enheten visas längst upp i fliken. Om det finns flera flikar, är bara en aktiv. Enhetsnamnet i den aktiva fliken visas med fetstil, och avgör den aktiva kostnadsenheten i &kcachegrind;s fönster.

#### Områden under en flik

Varje flik kan innehålla upp till fyra visningsområden, närmare bestämt uppe, höger, vänster och nere. Varje område kan innehålla flera visualiseringar ovanpå varandra. Den synliga delen av ett område väljes med en flikrad. Flikrader för det övre och högra området är längst upp, flikrader för det vänstra och nedre området är längst ner. Du kan ange vilka sorters visualiseringar som ska hamna i de olika områdena genom att använda flikarnas sammanhangsberoende menyer.

#### Synkroniserad vy med vald enhet under en flik

Förutom en aktiv enhet, har varje flik en vald enhet. Eftersom de flesta visualiseringstyper visar flera enheter med den aktiva centrerad på något sätt, kan du ändra valt objekt genom att navigera i en visualisering (genom att klicka med musen eller använda tangentbordet). Ofta visas valda objekt med markeringar. Genom att ändra vald enhet i en av visualiseringarna under fliken, markeras den nyvalda enheten i alla andra visualiseringar under fliken på motsvarande sätt.

#### Synkronisering mellan flikar

Om det finns flera flikar, gör en ändring av markeringen under en flik att en aktivering ändras under nästa flik (till höger eller nedanför). Den här sortens länkning bör till exempel möjliggöra snabb bläddring i anropsdiagram.

#### Layouter

Layouten för alla flikarna i ett fönster kan sparas (Visa Layout). Efter nuvarande layout har duplicerats (&Ctrl; + Visa Layout Duplicera) och någon storlek har ändrats eller en visualisering har flyttats till ett annat område under en flik, kan du snabbt byta mellan den gamla och den nya layouten via &Ctrl; Vänsterpil eller &Ctrl; Högerpil. Layoutuppsättningarna sparas mellan sessioner i &kcachegrind; med samma profileringskommando. Du kan göra den nuvarande layoutuppsättningen standard för nya sessioner i &kcachegrind;, eller återställa standarduppsättningen.

### Sidopaneler

#### Flat profil

Den flata profilen innehåller en grupp- och en funktionsvalslista. Grupplistan innehåller alla grupper där kostnader uppstår, beroende på markerad grupptyp. Grupplistan döljs när gruppering stängs av.

Funktionslistan innehåller funktionerna i den valda gruppen (eller alla funktioner om gruppering är avstängd), ordnade enligt någon kolumn, t.ex. ingående kostnad eller använd egenkostnad. Det finns ett maximalt antal funktioner som visas i listan, vilket kan ställas in med Inställningar Anpassa KCachegrind.

#### Översikt över delar

Under en profileringskörning kan flera profileringsdatafiler skapas, som kan laddas tillsammans i &kcachegrind;. Sidorutan Översikt över delar visar dem, horisontellt ordnade enligt tiden de skapades. Storleken på rektanglarna är proportionell mot kostnaden som uppstått i delarna. Du kan välja en eller flera delar för att begränsa kostnaderna som visas i övriga vyer i &kcachegrind; till bara dessa delar.

Delarna är ytterligare uppdelade mellan ett uppdelningsläge och ett samlat delningsläge med kostnad:

Uppdelningsläge

  Uppdelningen visas i grupper för en spårningsdatadel, enligt vald grupptyp. Om till exempel &ELF;-objektgrupper är valt, ser du färgade rektanglar för varje använt &ELF;-objekt (delat bibliotek eller körbart program), med storlek enligt ingående kostnad.

Diagramläge

  En rektangel som visar samlad kostnad för aktuell markerad funktion i delen visas. Den delas återigen upp, för att visa samlade kostnader för anropade funktioner.

#### Anropsstack

Det här är en rent uppdiktad mest trolig anropsstack. Den byggs upp genom att börja med aktuell markerad funktion och lägga till de som anropar och anropade med högst kostnad längst upp och längst ner.

Kolumnerna Kostnad och Anrop visar kostnad som behövs för alla anrop från funktionen på raden ovan.

### Vyer

#### Händelsetyp

Listan Händelsetyp visar alla tillgängliga kostnadsslag och vad som är egenkostnaden och samlade kostnaden för aktuell markerad funktion för kostnadsslagen.

Genom att välja en kostnadsslag i listan, ändrar du kostnadsslag för kostnader som visas överallt i &kcachegrind; till det valda.

#### Anropslistor

Listorna visar anrop till och från den nuvarande aktiva funktionen. Med Alla de som anropar och Alla anropade, menas funktioner som kan nås i båda riktningarna, även om andra funktioner finns emellan.

Anropslistans vy omfattar:

- De som anropar direkt

- De som blir anropade direkt

- Alla som anropar

- Alla som anropas

#### Mappningar

En visualisering med träddiagram av den primära händelsetypen, uppåt eller neråt i anropshierarkin. Varje färglagd rektangel motsvarar en funktion. Storleken är ungefär proportionell mot kostnaden som uppstår i den, medan den aktiva funktionen kör (det finns dock begränsningar i återgivningen).

För kartan över de som anropar, visar diagrammet hierarkin i flera nivåer för alla de som anropar den aktuella aktiverade funktionen. För kartan över de som blir anropade visar det hierarkin i flera nivåer för alla de som blir anropade av den aktuella aktiverade funktionen.

Utseendealternativ hittas i den sammanhangsberoende menyn. För att få exakta storleksförhållanden, välj Bara riktiga kanter. Eftersom läget kan ta mycket lång tid, kanske du först vill begränsa maximalt antal återgivna nivåer. Bäst avgör delningsriktningen för inre funktioner från den yttres proportion. Alltid bäst beslutar om återstående utrymme för varje funktion på samma nivå. Ignorera proportioner tar utrymme för att rita funktionsnamnet innan inre funktioner ritas. Observera att storleksförhållanden kan bli väsentligt felaktiga.

Tangentbordsnavigering är tillgänglig med vänster och höger piltangenter för att gå igenom objekt på samma nivå, och uppåt/neråt piltangenter för att gå upp eller ner en nivå, Returtangenten aktiverar aktuellt objekt.

#### Anropsdiagram

Den här vyn visar omgivningen till anropsdiagrammet för den aktiva funktionen. Kostnaden som visas är bara kostnaden som uppstår när den aktiva funktionen verkligen körde, dvs. kostnaden som visas för `main()`, om det syns, ska vara samma som kostanden för den aktiva funktionen, eftersom det är den del av den tillhörande kostnaden som uppstår i `main()` medan den aktiva funktionen kör.

För cykler, anger blåa anropspilar att det här är ett artificiellt anrop som lagts till för riktig uppritning, som i själva verket aldrig inträffat.

Om diagrammet är större än komponentens yta, visas en översiktsruta i ena hörnet. Det finns liknande visualiseringsalternativ som i anropsträdkartan. Den valda funktionen markeras.

#### Kommentarer

Den kommenterade källkoden eller assemblerlistan visar källkodsraderna eller maskinkodsinstruktionerna för aktuell markerad funktion tillsammans med (egen)kostnaden som uppstår när en källkodsrad eller instruktion utförs. Om det är en anropsinstruktion, infogas rader med information om anropet som sker i koden: Detta är den samlade kostnaden som uppstår inne i anropet, antal anrop som sker, och anropsmålet.

Markera en sådan rad med anropsinformation för att aktivera anropsmålet.

## Kommandoreferens

### &kcachegrind;s huvudfönster

#### Menyn Arkiv

&Ctrl;N Arkiv Ny

  Öppnar ett tomt toppnivåfönster där du kan ladda profileringsdata. Det här alternativet behövs egentligen inte, eftersom Arkiv Öppna... ger ett nytt toppnivåfönster om det nuvarande redan visar någon data.

&Ctrl;O Arkiv Öppna

  Visar &kde;:s fildialogruta för att välja en profileringsdatafil som ska läsas in. Om någon data redan visas i det nuvarande toppnivåfönstret, öppnar detta ett nytt fönster. Om du vill lägga till ytterligare profileringsdata i nuvarande fönster, använd Arkiv Lägg till.

  Profileringsdatafilernas namn slutar oftast med `.pid.part-threadID`, där part och threadID är valfria. pid och part används av flera profileringsdatafiler som tillhör en programkörning. Genom att ladda en fil som bara slutar med `pid`, laddas också eventuella befintliga datafiler, men med andra filändelser, för den här körningen.

  Om profileringsdatafilerna `cachegrind.out.123` och `cachegrind.out.123.1` finns, laddas också den andra automatiskt genom att ladda den första.

Arkiv Lägg till

  Lägger till en profileringsdatafil i nuvarande fönster. Genom att använda det kan du tvinga fram att flera datafiler laddas i samma toppnivåfönster även om de inte kommer från samma körning givet av konventionen för namngivning av profileringsdatafiler. Det kan till exempel användas för jämförelser.

F5 Arkiv Uppdatera

  Ladda om profileringsdata. Det är intressantast när en annan profileringsdatafil skapats för en programkörning som redan laddats.

&Ctrl;Q Arkiv Avsluta

  Avslutar &kcachegrind;

## Vanliga frågor

Vad är &kcachegrind; till för? Jag har ingen aning.

&kcachegrind; är till hjälp vid ett sent steg i programutveckling som kallas profilering. Om du inte utvecklar program, behöver du inte &kcachegrind;.

Vad är skillnaden mellan Inkl. och Själv?

De är kostnadsegenskaper för funktioner med avseende på en viss händelsetyp. Eftersom funktioner kan anropa varandra, är det rimligt att skilja på funktionens egen kostnad (självkostnad) och den samlade kostnaden inklusive alla anropade funktioner (inkluderande kostnad). Själv kallas också ibland egenkostnad.

Alltså kommer du till exempel alltid att ha en samlad kostnad av nästan 100 % för `main()`, medan egenkostnaden är försumbar när det verkliga arbetet utförs i en annan funktion.

Om jag dubbelklickar på en funktion i vyn Anropsdiagram, visas samma kostnad för `main()` som för den aktiverade funktionen. Är det inte meningen att den alltid ska vara 100 %?

Du har aktiverat en funktion under `main()` som har en lägre kostnad än `main()`. Bara den del av funktionens totala kostnad som används när den aktiverade funktionen kör visas för en funktion, dvs. kostnaden som visas för en funktion kan aldrig vara större än kostnaden för den aktiverade funktionen.

Kostnadsenhet

  Ett abstrakt objekt som hör ihop med källkod som kan tilldelas händelseantal. Dimensioner för kostnadsenheter är kodposition (t.ex. källkodsrad, funktion), dataposition (t.ex. använd datatyp, dataobjekt), körposition (t.ex. tråd, process) och kombinationer av nämnda positioner (t.ex. anrop, objekt använda av satser, data utkastad från cache).

Händelsekostnader

  Summering av händelser av en viss händelsetyp som inträffar medan körningen är kopplad till en viss kostnadsenhet. Kostnaden tilldelas till enheten.

Händelsetyp

  Den sortens händelse vars kostnad kan tilldelas till en kostnadsenhet. Det finns både verkliga händelsetyper och ärvda händelsetyper.

Ärvd händelsetyp

  En virtuell händelsetyp som bara syns i visualiseringen, som är definierad av en formel som beräknas från verkliga händelsetyper.

Profileringsdatafil

  En fil som innehåller data som mätts upp i ett profileringsexperiment (eller del av ett sådant) eller skapats vid efterbehandling av en spårning. Dess storlek är typiskt linjär i förhållande till programmets kodstorlek.

Profileringsdatadel

  Data från en profileringsdatafil.

Profileringsexperiment

  En programkörning övervakad av ett profileringsverktyg, som möjligen skapar flera profileringsdatafiler från delar av och/eller trådar i körningen.

Profileringsprojekt

  En inställning för profileringsexperiment som används för ett program som ska profileras, kanske i flera versioner. Jämförelser av profileringsdata är ofta bara meningsfullt mellan profileringsdata som skapas av experiment som görs inom ett profileringsprojekt.

Profilering

  Processen att samla in statistisk information om beteende under körning från programkörningar.

Verklig händelsetyp

  En händelstyp som kan mätas av ett verktyg. Det kräver att en sensor existerar för den givna händelsetypen.

Spårning

  En följd av tidsstämplade händelser som inträffat medan en programkörning spåras. Storleken är typiskt linjär i förhållande till programkörningens körtid.

Spårningsdel
Spåra

  Processen att övervaka en programkörning och lagra händelser som inträffar sorterade enligt tidsstämpling i en utdatafil, kallad spårning.

## Tack till och licens

Tack till Julian Seward för det utmärkta verktyget &valgrind;, och Nicholas Nethercote för tillägget &cachegrind;. Utan dessa program, skulle inte &kcachegrind; finnas. Vissa av idéerna för det grafiska gränssnittet kommer också från dem.

Tack för alla felrapporter och förslag från olika användare.

Översättning Stefan Asserhäll stefan.asserhall@bredband.net

&underFDL;

&documentation.index;