131
158
>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.</para>
134
>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.</para>
161
>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 <symbol
163
> i samplingsmetoden. Fördelen med sampling är att koden inte behöver ändras, men det är fortfarande en kompromiss: antagandet ovan är riktigare om <symbol
165
> är litet, men ju mindre <symbol
167
> är, desto större är tiden som går åt i avbrottshanteraren.</para>
137
170
>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.</para>
156
189
>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).</para>
159
>&oprofile; är ett systemprofileringsverktyg för &Linux; som använder sampling.</para>
192
>&oprofile; är ett systemprofileringsverktyg för &Linux; som använder sampling. </para>
162
195
>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. </para>
165
>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. </para>
198
>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 <emphasis
200
> 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. </para>
168
203
>&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. </para>
214
249
>&callgrind;</title>
217
>&callgrind; är en del av &valgrind;, <ulink url="http://valgrind.org"
218
>http://valgrind.org</ulink
252
>&callgrind; är en del av <ulink url="http://valgrind.org"
219
254
>. Observera att det tidigare kallades &calltree; men det namnet var missvisande. </para>
222
>Den vanligaste användningen är att inleda kommandot för att starta ditt program med <application
223
>valgrind --tool=callgrind</application
257
>Den vanligaste användningen är att inleda kommandot för att starta ditt program med <userinput
261
>--tool=callgrind</option
263
>, som med: <blockquote
227
>valgrind --tool=callgrind mitt_program mina_argument</command
269
>--tool=callgrind</option
271
>mitt_program</replaceable
273
>mina_väljare</replaceable
230
277
> När programmet avslutas skapas filen <filename
231
>callgrind.out.pid</filename
278
>callgrind.out.<replaceable
232
281
>, som kan laddas i &kcachegrind;. </para>
235
>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 <command
237
>, skulle du kunna bestämma att lagra data så fort du väljer menyalternativet Visa/Uppdatera. Det motsvarar ett anrop till <symbol
238
>KonqMainWindow::slotReload</symbol
284
>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 <menuchoice
288
>Uppdatera</guimenuitem
290
>. Det motsvarar ett anrop till <methodname
291
>KonqMainWindow::slotReload</methodname
239
292
>. Använd <blockquote
242
>valgrind --tool=callgrind --dump-before=KonqMainWindow::slotReload konqueror </command
298
>--tool=callgrind</option
300
>--dump-before=KonqMainWindow::slotReload</option
302
>konqueror</replaceable
245
306
> 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. </para>
254
315
>&oprofile; är tillgänglig från <ulink url="http://oprofile.sf.net"
255
>http://oprofile.sf.net</ulink
256
317
>. 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;). </para>
259
320
>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 <command
260
321
>oprof_start</command
261
>, eller kommandoradverktyget opcontrol. Standardinställningen ska vara tidsläge (TBS, se inledningen). För att starta mätningen, kör <command
262
>opcontrol -s</command
263
>. Kör därefter programmet du är intresserad av, och skriv efteråt <command
264
>opcontrol -d</command
265
>. Det skriver ut mätresultaten i filer under katalogen <filename
322
>, eller kommandoradverktyget <command
324
>. Standardinställningen ska vara tidsläge (TBS, se inledningen). För att starta mätningen, kör <userinput
330
>. Kör därefter programmet du är intresserad av, och skriv efteråt <userinput
336
>. Det skriver ut mätresultaten i filer under katalogen <filename class="directory"
266
337
>/var/lib/oprofile/samples/</filename
267
338
>. För att kunna visualisera data i &kcachegrind; gör följande i en tom katalog: <blockquote
270
>opreport -gdf | op2callgrind</command
346
>op2callgrind</command
273
350
> 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. </para>
287
>Öppna...</guimenuitem
289
366
>, 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. </para>
292
>Efter första starten, är området uppdelat i en övre och en undre del, var och en med olika visualiseringar som kan väljas med flikar. För att flytta visualiseringsvyer, använd flikarnas sammanhangsberoende meny, och justera avdelaren mellan visualiseringarna. För att snabbt byta mellan olika visualiseringslayouter, använd Visa/Layout/Duplicera, ändra layouten och byt mellan layouter med Visa/Layout/Nästa (eller ännu bättre, använd motsvarande snabbtangenter). </para>
369
>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 <menuchoice
371
><keycombo action="simul"
381
>Gå till nästa</guimenuitem
385
><keycombo action="simul"
395
>Gå till föregående</guimenuitem
295
>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 händelsetypvyn. En första översikt över beteendet under körning bör ges när du väljer funktionen <symbol
400
>Den aktiva händelsetypen är viktig för visualiseringarna: för &callgrind; är det till exempel cachemissar eller cykeluppskattningar, för &oprofile; är det <quote
402
> i det enklaste fallet. Du kan ändra händelsetyp via en kombinationsruta i verktygsraden eller i vyn <guilabel
403
>Händelsetyp</guilabel
404
>. En första översikt över beteendet under körning bör ges när du väljer funktionen <function
297
406
> 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. </para>
300
>För att utforska det grafiska gränssnittet ytterligare, förutom den här handboken, ta också en titt på dokumentationsavsnittet på webbsidan <ulink url="http://kcachegrind.sf.net"
301
>http://kcachegrind.sf.net</ulink
409
>För att utforska det grafiska gränssnittet ytterligare, förutom den här handboken, ta också en titt på dokumentationsavsnittet <ulink url="http://kcachegrind.sf.net"
302
411
>. Förutom detta, har varje grafisk komponent i &kcachegrind; hjälp via <quote
303
412
>Vad är det här?</quote
326
435
>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. </para>
329
>Kostnadsenheterna som &kcachegrind; känner till anges här. Enkla positioner: <itemizedlist
332
>Instruktion. En assemblerinstruktion på en given adress.</para
336
>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 "???".</para
340
>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/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 "???".</para
344
>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.</para
348
>Källkodsfil. Alla funktioner vars första instruktion avbildas till en rad i den givna källkodsfilen.</para
352
>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.</para
356
>Profileringsdel. Ett visst tidsavsnitt av en profileringskörning, med ett givet tråd-id, process-id och kommandorad som kördes.</para
438
>Kostnadsenheterna som &kcachegrind; känner till anges här. Enkla positioner: <variablelist
444
>En assemblerinstruktion på en given adress.</para
449
>Källkodsrad i en funktion</term
452
>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 <filename
462
>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 <function
466
>. 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 <function
476
> Alla funktioner vars kod är inne i ett givet binärobjekts område, antingen i det körbara huvudprogrammet eller ett delat bibliotek.</para
484
>Alla funktioner vars första instruktion avbildas till en rad i den givna källkodsfilen.</para
492
> 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.</para
497
>Profileringsdel</term
500
> Ett visst tidsavsnitt av en profileringskörning, med ett givet tråd-id, process-id och kommandorad som kördes.</para
359
504
> 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. </para>
464
>Visualiseringsområde</title>
466
>Visualiseringsområdet, typiskt den högra delen av ett huvudfönster i &kcachegrind;, består av en (förvalt värde) eller flera flikvyer, antingen uppradade horisontellt eller vertikalt. Varje flikvy innehåller olika visualiseringsvyer av en enda kostnadsenhet åt gången. Namnet på enheten visas längst upp i flikvyn. Om det finns flera flikvyer, är bara en aktiv. Enhetsnamnet i den aktiva flikvyn visas med fetstil, och avgör den aktiva kostnadsenheten i &kcachegrind;s fönster. </para>
471
>Områden i en flikvy</title>
473
>Varje flikvy 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 visualiseringsvyer 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. </para>
478
>Synkroniserad visualisering via vald enhet i en flikvy</title>
480
>Förutom en aktiv enhet, har varje flikvy 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 i flikvyn, markeras den nyvalda enheten i alla andra visualiseringar i flikvyn på motsvarande sätt. </para>
485
>Synkronisering mellan flikvyer</title>
487
>Om det finns flera flikvyer, gör en ändring av markeringen i en flikvy att en aktivering ändras i nästa flikvy (till höger eller nedanför). Den här sortens länkning bör till exempel möjliggöra snabb bläddring i anropsdiagram. </para>
618
>Visualiseringsområdet</title>
620
>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. </para>
625
>Områden under en flik</title>
627
>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. </para>
632
>Synkroniserad vy med vald enhet under en flik</title>
634
>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. </para>
639
>Synkronisering mellan flikar</title>
641
>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. </para>
492
646
>Layouter</title>
494
>Layouten för alla flikvyerna i ett fönster kan sparas (se menyalternativet Visa/Layout). Efter nuvarande layout har duplicerats (Ctrl+Plus eller meny) och någon storlek har ändrats eller en visualiseringsvy har flyttats till ett annat område i en flikvy, 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. </para>
648
>Layouten för alla flikarna i ett fönster kan sparas (<menuchoice
654
>). Efter nuvarande layout har duplicerats (<menuchoice
656
><keycombo action="simul"
666
>Duplicera</guimenuitem
668
>) 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 <keycombo action="simul"
672
> eller <keycombo action="simul"
676
>. 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. </para>
506
688
>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. </para>
508
>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;. </para>
690
>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 <menuchoice
692
>Inställningar</guimenu
694
>Anpassa KCachegrind</guimenuitem
513
701
>Översikt över delar</title>
515
>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. </para>
703
>Under en profileringskörning kan flera profileringsdatafiler skapas, som kan laddas tillsammans i &kcachegrind;. Sidorutan <guilabel
704
>Översikt över delar</guilabel
705
> 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. </para>
517
>Delarna är ytterligare uppdelade: Det finns ett uppdelningsläge och ett samlat delningsläge: <itemizedlist>
520
>Uppdelning: Du ser en uppdelning i grupper för en spårningsdel, 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. </para
524
>Samlad delning: En rektangel som visar samlad kostnad för aktuell markerad funktion i spårningsdelen visas. Den delas återigen upp, för att visa samlade kostnader för anropade funktioner. </para
707
>Delarna är ytterligare uppdelade mellan ett uppdelningsläge och ett samlat delningsläge med kostnad: <variablelist>
711
>Uppdelningsläge</guilabel
715
>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. </para
721
>Diagramläge</guilabel
725
>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. </para
532
734
>Anropsstack</title>
534
>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. </para>
736
>Det här är en rent uppdiktad <quote
738
> 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. </para>
536
>Kolumnerna 'Kostnad' och 'Anrop' visar kostnad som behövs för alla anrop från funktionen på raden ovan. </para>
740
>Kolumnerna <guilabel
744
> visar kostnad som behövs för alla anrop från funktionen på raden ovan. </para>
540
<sect1 id="concepts-visualizations">
748
<sect1 id="concepts-views">
542
>Visualiseringar</title>
546
>Händelsetyper</title>
548
>Det här listan visar alla tillgängliga kostnadsslag och vad som är egenkostnaden och samlade kostnaden för aktuell markerad funktion för kostnadsslagen. </para>
757
>Händelsetyp</guilabel
758
> visar alla tillgängliga kostnadsslag och vad som är egenkostnaden och samlade kostnaden för aktuell markerad funktion för kostnadsslagen. </para>
550
760
>Genom att välja en kostnadsslag i listan, ändrar du kostnadsslag för kostnader som visas överallt i &kcachegrind; till det valda. </para>
555
765
>Anropslistor</title>
557
>Listorna visar anrop till/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. </para>
767
>Listorna visar anrop till och från den nuvarande aktiva funktionen. Med <guilabel
768
>Alla de som anropar</guilabel
770
>Alla anropade</guilabel
771
>, menas funktioner som kan nås i båda riktningarna, även om andra funktioner finns emellan. </para>
559
774
>Anropslistans vy omfattar: <itemizedlist>
562
>De som direkt anropar </para
566
>Direkta anrop </para
570
>Alla som anropar </para
574
>Alla som anropas </para
777
>De som anropar direkt</para
781
>De som blir anropade direkt</para
786
>Alla som anropar</guilabel
792
>Alla som anropas</guilabel
582
801
>Mappningar</title>
584
>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 försöker vara proportionell mot kostnaden som uppstår i den, medan den aktiva funktionen kör (det finns dock begränsningar i uppritningen). </para>
803
>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). </para>
586
805
>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. </para>
588
>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 uppritade 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. </para>
807
>Utseendealternativ hittas i den sammanhangsberoende menyn. För att få exakta storleksförhållanden, välj <guimenuitem
808
>Bara riktiga kanter</guimenuitem
809
>. Eftersom läget kan ta mycket lång tid, kanske du först vill begränsa maximalt antal återgivna nivåer. <guilabel
811
> avgör delningsriktningen för inre funktioner från den yttres proportion. <guilabel
812
>Alltid bäst</guilabel
813
> beslutar om återstående utrymme för varje funktion på samma nivå. <guilabel
814
>Ignorera proportioner</guilabel
815
> tar utrymme för att rita funktionsnamnet innan inre funktioner ritas. Observera att storleksförhållanden kan bli väsentligt felaktiga. </para>
590
>Tangentbordsnavigering är tillgänglig med vänster/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. </para>
817
>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. </para>
595
822
>Anropsdiagram</title>
597
>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. </para>
824
>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 <function
826
>, 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 <function
828
> medan den aktiva funktionen kör. </para>
599
>För cykler, anger blåa anropspilar att det här är ett artificiellt anrop som lagts till för att riktig uppritning, som i själva verket aldrig inträffat. </para>
830
>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. </para>
601
832
>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. </para>
674
905
>Öppna</guimenuitem
680
>Visar fildialogrutan för att välja en profileringsdatafil som ska laddas.</action
681
> 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 <menuchoice
911
>Visar &kde;:s fildialogruta</action
912
> 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 <menuchoice
685
>Lägg till...</guimenuitem
916
>Lägg till</guimenuitem
689
>Profileringsdatafilernas namn slutar oftast med '.pid.part-threadID', där 'part' och 'threadID' är valfritt 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. </para>
691
>Till exempel om profileringsdatafilerna cachegrind.out.123 och cachegrind.out.123.1 finns, laddas också den andra automatiskt genom att ladda den första. </para
920
>Profileringsdatafilernas namn slutar oftast med <literal role="extension"
926
>threadID</replaceable
931
>threadID</replaceable
932
> är valfria. <replaceable
936
> används av flera profileringsdatafiler som tillhör en programkörning. Genom att ladda en fil som bara slutar med <literal role="extension"
940
>, laddas också eventuella befintliga datafiler, men med andra filändelser, för den här körningen. </para>
943
>Om profileringsdatafilerna <filename
944
>cachegrind.out.123</filename
946
>cachegrind.out.123.1</filename
947
> finns, laddas också den andra automatiskt genom att ladda den första. </para
878
>Vad är skillnaden mellan 'Inkl.' och 'Själv'? </para>
882
>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älv') och den samlade kostnaden inklusive alla anropade funktioner ('Inkl.'). 'Själv' kallas också ibland egenkostnad. </para>
884
>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. </para>
891
>Verktygsraden och menyraden i min &kcachegrind; ser så spartansk ut. Är det normalt?</para>
895
>Uppenbarligen är &kcachegrind; felinstallerat på ditt system. Du rekommenderas att kompilera med installeringsprefixet satt till &kde;:s baskatalog i systemet, som <command
896
>configure --prefix=/opt/kde4; make install</command
897
>. Om du väljer en annan katalog, som $HOME/kde, måste du ställa in miljövariabeln KDEDIR till den katalogen innan du kör &kcachegrind;. </para>
904
>Om jag dubbelklickar på en funktion i anropsdiagramvyn, visas samma kostnad för main som för den aktiverade funktionen. Är det inte meningen att den alltid ska vara 100 %? </para>
908
>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. </para>
1042
>Vad är skillnaden mellan <guilabel
1050
>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 (<quote
1051
>självkostnad</quote
1052
>) och den samlade kostnaden inklusive alla anropade funktioner (<quote
1053
>inkluderande kostnad</quote
1056
> kallas också ibland <quote
1060
>Alltså kommer du till exempel alltid att ha en samlad kostnad av nästan 100 % för <function
1062
>, medan egenkostnaden är försumbar när det verkliga arbetet utförs i en annan funktion. </para>
1069
>Verktygsraden och menyraden i min &kcachegrind; ser så spartanska ut. Är det normalt?</para>
1073
>Uppenbarligen är &kcachegrind; felinstallerat på ditt system. Du rekommenderas att kompilera med installeringsprefixet satt till &kde;:s baskatalog i systemet, som <userinput
1076
>--prefix=<replaceable
1077
>/opt/kde4</replaceable
1081
>make install</command
1083
>. Om du väljer en annan katalog, som <filename class="directory"
1087
>, måste du ställa in miljövariabeln <envar
1089
> till den katalogen innan du kör &kcachegrind;. </para>
1096
>Om jag dubbelklickar på en funktion i vyn <guilabel
1097
>Anropsdiagram</guilabel
1098
>, visas samma kostnad för <function
1100
> som för den aktiverade funktionen. Är det inte meningen att den alltid ska vara 100 %? </para>
1104
>Du har aktiverat en funktion under <function
1106
> som har en lägre kostnad än <function
1108
>. Bara den del av funktionens totala kostnad som används när den <emphasis
1109
>aktiverade</emphasis
1110
> 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. </para>
916
<chapter id="glossary">
921
>Det följande är en blandad lista med termer. <itemizedlist>
924
>Profilering: Processen att samla in statistisk information om beteende under körning från programkörningar. </para
928
>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. </para
932
>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. </para
936
>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. </para
940
>Profileringsdatadel (inkorrekt används också spårningsdel): Data från en profileringsdatafil. </para
944
>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. </para
948
>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. </para
952
>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). </para
956
>Händelsetyp: Den sortens händelse vars kostnad kan tilldelas till en kostnadsenhet. Det finns både verkliga händelsetyper och ärvda händelsetyper. </para
960
>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. </para
964
>Ä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. </para
968
>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. </para
1121
<glossentry id="costentity">
1123
>Kostnadsenhet</glossterm>
1126
>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).</para
1130
<glossentry id="eventcosts">
1132
>Händelsekostnader</glossterm>
1135
>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.</para
1139
<glossentry id="eventtype">
1141
>Händelsetyp</glossterm>
1144
>Den sortens händelse vars kostnad kan tilldelas till en kostnadsenhet. Det finns både verkliga händelsetyper och ärvda händelsetyper.</para
1148
<glossentry id="inheritedeventtype">
1150
>Ärvd händelsetyp</glossterm>
1153
>En virtuell händelsetyp som bara syns i visualiseringen, som är definierad av en formel som beräknas från verkliga händelsetyper.</para
1157
<glossentry id="profiledatafile">
1159
>Profileringsdatafil</glossterm>
1162
>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.</para
1166
<glossentry id="profiledatapart">
1168
>Profileringsdatadel</glossterm>
1171
>Data från en profileringsdatafil.</para
1175
<glossentry id="profileexperiment">
1177
>Profileringsexperiment</glossterm>
1180
>En programkörning övervakad av ett profileringsverktyg, som möjligen skapar flera profileringsdatafiler från delar av och/eller trådar i körningen.</para
1184
<glossentry id="profileproject">
1186
>Profileringsprojekt</glossterm>
1189
>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.</para
1193
<glossentry id="profiling">
1195
>Profilering</glossterm>
1198
>Processen att samla in statistisk information om beteende under körning från programkörningar.</para
1202
<glossentry id="realeventtype">
1204
>Verklig händelsetyp</glossterm>
1207
>En händelstyp som kan mätas av ett verktyg. Det kräver att en sensor existerar för den givna händelsetypen.</para
1211
<glossentry id="trace">
1213
>Spårning</glossterm>
1216
>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.</para
1220
<glossentry id="tracepart">
1222
>Spårningsdel</glossterm>
1223
<glosssee otherterm="profiledatapart"/>
1226
<glossentry id="tracing">
1231
>Processen att övervaka en programkörning och lagra händelser som inträffar sorterade enligt tidsstämpling i en utdatafil, kallad spårning.</para
974
1237
<chapter id="credits">
978
1240
>Tack till och licens</title>
983
1243
>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. </para>
985
>Och tack för alla felrapporter och förslag från olika användare. </para>
1245
>Tack för alla felrapporter och förslag från olika användare. </para>
988
1248
>Översättning Stefan Asserhäll <email
added
removed
docs/kdesdk/kcachegrind/index.docbook
