Profilering (datorprogrammering) - Profiling (computer programming)

Mjukvaruutveckling
Kärnaktiviteter
Paradigmer och modeller
Metoder och ramar
Stödjande discipliner
Övningar
Verktyg
Standarder och kunskapsorgan
Ordlistor
Konturer

I programvaruteknik är profilering ("programprofilering", "programvaruprofilering") en form av dynamisk programanalys som mäter till exempel utrymmet (minnet) eller tidskomplexiteten i ett program , användningen av specifika instruktioner eller frekvensen och funktionssamtalens varaktighet. Vanligtvis tjänar profileringsinformation till att hjälpa programoptimering , och mer specifikt, prestandateknik .

Profilering uppnås genom instrumen antingen programkällkoden eller dess binära form med användning av ett verktyg som kallas en profilerare (eller kod profiler ). Profilers kan använda ett antal olika tekniker, till exempel händelsebaserade, statistiska, instrumenterade och simuleringsmetoder.

Samla programevenemang

Profiler använder en mängd olika tekniker för att samla in data, inklusive maskinvarustörningar , kodinstrument , instruktionsuppsättningssimulering , operativsystems krokar och prestandaräknare .

Användning av profiler

Image
Grafisk produktion av CodeAnalyst- profilen.

Programanalysverktyg är oerhört viktiga för att förstå programbeteende. Datorarkitekter behöver sådana verktyg för att utvärdera hur bra program kommer att fungera på nya arkitekturer . Programvaruskribenter behöver verktyg för att analysera sina program och identifiera kritiska delar av koden. Kompilatorförfattare använder ofta sådana verktyg för att ta reda på hur bra deras instruktionsplanering eller algoritm för förutsägelse av filialer fungerar ...

-  ATOM, PLDI , '94

Resultatet från en profil kan vara:

  • En statistisk sammanfattning av de observerade händelserna (en profil )
Sammanfattningsprofilinformation visas ofta antecknat mot källkodsuttalanden där händelserna inträffar, så storleken på mätdata är linjär i förhållande till programmets kodstorlek.
/* ------------ source------------------------- count */             
0001             IF X = "A"                     0055
0002                THEN DO                       
0003                  ADD 1 to XCOUNT           0032
0004                ELSE
0005             IF X = "B"                     0055
  • En ström av inspelade händelser (ett spår )
För sekventiella program är en sammanfattningsprofil vanligtvis tillräcklig, men prestandaproblem i parallella program (väntar på meddelanden eller synkroniseringsproblem) beror ofta på tidsförhållandet mellan händelserna, vilket kräver ett fullständigt spår för att få en förståelse för vad som händer.
Storleken på ett (fullständigt) spår är linjärt i förhållande till programmets instruktionsväg , vilket gör det något opraktiskt. Ett spår kan därför initieras vid en punkt i ett program och avslutas vid en annan punkt för att begränsa utmatningen.
  • En pågående interaktion med hypervisor (kontinuerlig eller periodisk övervakning via skärmvisning till exempel)
Detta ger möjlighet att slå på eller av ett spår vid vilken önskad punkt som helst under körning förutom att visa löpande mätvärden om programmet (fortfarande körs). Det ger också möjlighet att avbryta asynkrona processer vid kritiska punkter för att undersöka interaktioner med andra parallella processer mer detaljerat.

En profiler kan tillämpas på en enskild metod eller i skala för en modul eller ett program för att identifiera prestanda flaskhalsar genom att göra långvarig kod uppenbar. En profiler kan användas för att förstå kod från en tidpunkt, i syfte att optimera den för att hantera olika körtidstillstånd eller olika belastningar. Profileringsresultat kan tas in av en kompilator som ger profilstyrd optimering . Profileringsresultat kan användas för att styra design och optimering av en enskild algoritm; den Krauss matchande joker algoritmen är ett exempel. Profilers är inbyggda i vissa system för hantering av applikationsprestanda som samlar profildata för att ge insikt i transaktionsarbetsbelastningar i distribuerade applikationer.

Historia

Prestationsanalysverktyg fanns på IBM / 360- och IBM / 370- plattformar från början av 1970-talet, vanligtvis baserat på timeravbrott som registrerade programstatusordet (PSW) vid inställda timerintervaller för att upptäcka "hot spots" vid körning av kod. Detta var ett tidigt exempel på provtagning (se nedan). I början av 1974 tillät instruktionsuppsättningssimulatorer full spårning och andra prestandaövervakningsfunktioner.

Profiler-driven programanalys på Unix går tillbaka till 1973, då Unix-system innehöll ett grundläggande verktyg prof, som listade varje funktion och hur mycket av programkörningstiden den använde. 1982 gprofutvidgade konceptet till en fullständig analys av samtalsdiagram .

År 1994 publicerade Amitabh Srivastava och Alan Eustace från Digital Equipment Corporation en uppsats som beskriver ATOM (Analysis Tools with OM). ATOM-plattformen konverterar ett program till en egen profil: vid kompileringstiden infogar det kod i programmet som ska analyseras. Den infogade koden matar ut analysdata. Denna teknik - att modifiera ett program för att analysera sig själv - kallas " instrumentation ".

År 2004 gprofuppträdde både och ATOM-tidningarna på listan över de 50 mest inflytelserika PLDI- tidningarna för 20-årsperioden som slutade 1999.

Profiltyper baserat på utdata

Platt profil

Platta profiler beräknar de genomsnittliga samtalstiderna från samtalen och bryter inte ner samtalstiderna baserat på callee eller kontext.

Profiler för anropsdiagram

Samtals graf profilerare visar samtalstider och frekvenserna för funktioner och även samtalskedjor involverade baserat på den uppringda. I vissa verktyg bevaras inte hela sammanhanget.

Ingångskänslig profil

Ingångskänsliga profiler lägger till ytterligare en dimension till platt- eller anropsdiagramprofiler genom att relatera prestandamått till funktionerna hos de inmatade arbetsbelastningarna, såsom ingångsstorlek eller inmatningsvärden. De genererar diagram som karakteriserar hur en applikations prestanda skalas som en funktion av dess inmatning.

Datagranularitet i profiltyper

Profilers, som också själva är program, analyserar målprogram genom att samla in information om deras utförande. Baserat på deras datagranularitet, på hur profiler samlar in information, klassificeras de i händelsebaserade eller statistiska profiler. Profilers avbryter programkörningen för att samla in information, vilket kan resultera i en begränsad upplösning i tidsmätningarna, som bör tas med ett saltkorn. Grundläggande blockprofiler rapporterar ett antal maskinklockcykler som ägnas åt att utföra varje kodrad, eller en tidpunkt baserad på att lägga till dessa tillsammans; de rapporterade tidpunkterna per grundblock kanske inte återspeglar en skillnad mellan cache- träffar och missningar.

Eventbaserade profiler

Programmeringsspråken som listas här har evenemangsbaserade profiler:

  • Java : JVMTI (JVM Tools Interface) API, tidigare JVMPI (JVM Profiling Interface), tillhandahåller krokar till profiler för att fånga händelser som samtal, klassladdning, lossning, trådträff.
  • .NET : Kan bifoga en profileringsagent som en COM- server till CLR med hjälp av Profiling API . Precis som Java ger runtime sedan olika återuppringningar till agenten, för att fånga händelser som metod JIT / enter / leave, skapande av objekt, etc. Särskilt kraftfull genom att profilagenten kan skriva om målapplikationens bytkod på godtyckliga sätt.
  • Python : Python-profilering inkluderar profilmodulen, hotshot (som är samtalsgrafbaserad) och använder funktionen 'sys.setprofile' för att fånga händelser som c_ {call, return, exception}, python_ {call, return, exception}.
  • Ruby : Ruby använder också ett liknande gränssnitt som Python för profilering. Platt-profiler i profile.rb, modul och ruby-prof en C-förlängning finns.

Statistiska profiler

Vissa profiler fungerar genom provtagning . En provtagning profiler sonder målprogrammet s anropsstacken med jämna mellanrum med hjälp av operativsystemet avbrott . Provtagningsprofiler är vanligtvis mindre numeriskt noggranna och specifika, men låter målprogrammet köras med full hastighet.

De resulterande uppgifterna är inte exakta, utan en statistisk approximation. "Den faktiska mängden fel är vanligtvis mer än en samplingsperiod. Om ett värde är n gånger samplingsperioden är det förväntade felet i kvadratroten av n samplingsperioder."

I praktiken kan samplingsprofiler ofta ge en mer exakt bild av målprogrammets utförande än andra tillvägagångssätt, eftersom de inte är så påträngande för målprogrammet och därmed inte har så många biverkningar (t.ex. på minnescacher eller instruktioner) avkodning av rörledningar). Eftersom de inte påverkar körningshastigheten lika mycket kan de upptäcka problem som annars skulle döljas. De är också relativt immuna mot att övervärdera kostnaden för små, ofta kallade rutiner eller "snäva" öglor. De kan visa den relativa tiden som spenderas i användarläge kontra avbrytbar kärnläge som systemanropsbehandling .

Ändå medför kärnkod för att hantera avbrott en mindre förlust av CPU-cykler, vidarekopplad cacheanvändning och kan inte urskilja de olika uppgifterna som uppstår i avbrottsfri kärnkod (mikrosekundaktivitet).

Dedikerad hårdvara kan gå utöver detta: ARM Cortex-M3 och några nyligen MIPS-processorer JTAG-gränssnitt har ett PCSAMPLE-register, som samplar programräknaren på ett riktigt oupptäckbart sätt, vilket möjliggör icke-påträngande insamling av en platt profil.

Några vanliga statistiska profilerare för Java / hanterad kod är Smartbear Software 's AQtime och Microsofts ' s CLR Profiler . Dessa profiler stöder också inbyggd kodprofilering, tillsammans med Apple Inc .: s Shark (OSX), OProfile (Linux), Intel VTune och Parallel Amplifier (en del av Intel Parallel Studio ) och Oracle Performance Analyzer , bland andra.

Instrumentation

Denna teknik lägger effektivt till instruktioner i målprogrammet för att samla in nödvändig information. Observera att instrumentering av ett program kan orsaka prestationsförändringar och i vissa fall kan leda till felaktiga resultat och / eller heisenbugs . Effekten beror på vilken information som samlas in, på nivån på rapporterade tidsdetaljer och på om grundläggande blockprofilering används i samband med instrumentering. Till exempel att lägga till kod för att räkna varje procedur / rutinanrop kommer troligen att ha mindre effekt än att räkna hur många gånger varje uttalande följs. Några datorer har speciell hårdvara för att samla in information; i detta fall är påverkan på programmet minimal.

Instrumentering är nyckeln till att bestämma nivån på kontrollen och hur lång tid upplösningen är tillgänglig för profilerna.

  • Manual : utförs av programmeraren, till exempel genom att lägga till instruktioner för att uttryckligen beräkna driftstider, helt enkelt räkna händelser eller samtal till mät- API: er som Application Response Measurement- standarden.
  • Automatisk källnivå : instrumentering läggs till källkoden av ett automatiskt verktyg enligt en instrumentpolicy.
  • Mellanspråk : instrumentering läggs till vid montering eller dekompilerade bytkoder som ger stöd för flera källspråk på högre nivå och undviker (icke-symboliska) binära offset-omskrivningsproblem.
  • Kompilatorassisterad
  • Binär översättning : Verktyget lägger till instrumentering i en sammanställd körbar fil .
  • Runtime-instrumentering : Koden instrumenteras direkt före körning. Programkörningen övervakas och styrs helt av verktyget.
  • Runtime-injektion : Lättare än instrumentets runtime. Koden ändras vid körning för att hoppa till hjälpfunktioner.

Tolkinstrumentation

  • Alternativ för tolkfelsökning kan möjliggöra insamling av prestandamätvärden när tolk möter varje måluttalande. En bytkod , styrtabell eller JIT- tolkar är tre exempel som vanligtvis har fullständig kontroll över exekvering av målkoden, vilket möjliggör extremt omfattande möjligheter till datainsamling.

Hypervisor / simulator

  • Hypervisor : Data samlas in genom att köra det (vanligtvis) omodifierade programmet under en hypervisor . Exempel: SIMMON
  • Simulator och Hypervisor : Data samlas interaktivt och selektivt genom att köra det omodifierade programmet under en instruktionsuppsättningssimulator .

Se även

Referenser

externa länkar