A szoftverfejlesztésben a profilozás („program profilozás”, „szoftver profil”) a dinamikus programelemzés egy formája, amely például a program hely- (memória) vagy időbeli összetettségét, az egyes utasítások felhasználását vagy a funkcióhívások gyakoriságát és időtartamát méri. A profilozási információkat a program optimalizálásában használják fel.
A profilozást úgy érhetjük el, hogy a program forráskódját vagy annak bináris futtatható formáját instrumentáljuk egy „profilozó”-nak (vagy kódprofilozónak) nevezett eszközzel. A profilozók számos különféle technikát használhatnak, például eseményalapú, statisztikai, műszeres és szimulációs módszereket.
Programesemények összegyűjtése A profilkészítők sokféle technikát használnak az adatok gyűjtésére, ideértve a hardvermegszakításokat, a kódmérést, az utasításkészlet-szimulációt, az operációs rendszer kampóit és a teljesítményszámlálókat. A profilokat használják a teljesítménymérnöki folyamatban.
Profilerek használata
A profilozó kimenete lehet:
A megfigyelt események statisztikai összefoglalása (profil) Az összefoglaló profilinformációkat gyakran jelöléssel látják el a forráskód-kijelentésekkel szemben, ahol az események bekövetkeznek, tehát a mérési adatok mérete arányos a program kódméretével.
/* ------------ source------------------------- count */ 0001 IF X = "A" 0055 0002 THEN DO 0003 ADD 1 to XCOUNT 0032 0004 ELSE 0005 IF X = "B" 0055
A rögzített események stream-je (trace) A szekvenciális programokhoz általában elegendő az összefoglaló profil, de a párhuzamos programok (üzenetvárakozás vagy szinkronizálási problémák) teljesítményproblémái gyakran az események időbeli viszonyától függenek, így teljes nyomkövetésre van szükség a történtek megértéshez. A (teljes) nyomkövetés mérete lineárisan arányos a program utasítási útvonalának hosszával, ami kissé célszerűtlenné teszi. Ezért a nyomkövetés a program egyik pontján inicializálható, és egy másik ponton befejezhető a kimenet korlátozása érdekében. Folyamatos interakció a hypervisor-ral (folyamatos vagy időszakos monitorozás például a képernyőn keresztül) Ez lehetőséget ad arra, hogy a nyomkövetést a végrehajtás során bármely kívánt ponton be- vagy kikapcsolhassa, a folyamatban lévő metrikák megtekintése mellett a (még mindig végrehajtó) programról. Ezenkívül lehetőséget ad arra, hogy az aszinkron folyamatokat felfüggesszük a kritikus pontokon, hogy részletesebben megvizsgáljuk az egyéb párhuzamos folyamatokkal való interakciókat.
A profilozó alkalmazható egyedi módszerre vagy egy modul vagy program terjedelmében, a teljesítmény szűk keresztmetszeteinek azonosításához a hosszan futó kód nyilvánvalóvá tétele révén. A profilozó felhasználható a kód időzítés szempontjából történő megértésére, azzal a céllal, hogy optimalizálja azt a különböző futási feltételek vagy különböző terhelések kezelésére. A profilozási eredmények felhasználhatók az egyes algoritmusok tervezésének és optimalizálásának irányításához. A profilozók be vannak építve néhány alkalmazás teljesítménykezelő rendszerébe, amelyek összesítik a profilozási adatokat, hogy betekintést nyújtsanak a tranzakciós munkaterhelésébe az elosztott alkalmazásokban.
Történelem A teljesítmény-elemző eszközök az 1970-es évek elejétől léteztek az IBM / 360 és az IBM / 370 platformokon, általában olyan időzítő megszakításokon alapultak, amelyek meghatározott időközönként rögzítették a program állapotszót (PSW) a "forró pontok" észlelésére a futtatott kódban. Ez a mintavétel korai példája (lásd alább). 1974 elején az utasításkészlet-szimulátorok teljes nyomkövetést és egyéb teljesítmény-figyelő funkciókat tettek lehetővé.
A profilozás-vezérelt program elemzése a Unixon 1973-ba nyúlik vissza, amikor a Unix rendszerek tartalmaztak egy alapvető eszközt, a prof-ot, amely felsorolta az egyes függvényeket, és hogy azok a program futási idejének mekkora részét vették igénybe. 1982-ben a gprof kiterjesztette a koncepciót egy teljes hívás gráf elemzésre.S.L. Graham, P.B. Kessler, and M.K. McKusick, gprof: a Call Graph Execution Profiler, Proceedings of the SIGPLAN '82 Symposium on Compiler Construction, SIGPLAN Notices, Vol. 17, No 6, pp. 120-126; doi:10.1145/800230.806987
1994-ben Amitabh Srivastava és Alan Eustace a Digital Equipment Corporation-ből publikáltak egy tanulmányt, amelyben leírják az ATOM-ot (Analysis Tools with OM). Az ATOM platform egy programot a saját profilozójává konvertál: fordításkor illeszt be kódot az analizálandó programba. Ez a beillesztett kód elemzési adatokat szolgáltat. Ez a technika - egy program módosítása önmagának elemzésére - „instrumentation” néven ismert.
2004-ben mind a gprof, mind az ATOM tanulmányok megjelentek az 50 legbefolyásosabb PLDI tanulmányok listáján az 1999-ben záruló 20 éves időszakra.20 Years of PLDI (1979–1999): A Selection, Kathryn S. McKinley, Editor
Profiltípusok a kimenet alapján
Lapos profilozó (Flat profiler)
Hívási-gráf profilozó (Call-graph profiler) A lapos profilozók kiszámítják az átlagos hívási időket a hívások alapján, és nem bontják fel a hívási időket a hívó fél vagy a környezet alapján.
Bemenet érzékeny profilozó Bemenet érzékeny profilozók hozzáadnak egy további dimenziót a lapos vagy hívás-gráfos profilozókhoz, a teljesítménymutatóknak a bemeneti munkaterhelések jellemzőivel való összekapcsolásával, például a bemenet méretével vagy a bemeneti értékekkel. Diagramokat generálnak, amelyek jellemzik, hogy az alkalmazás teljesítménye hogyan alakul a bemenet függvényében.
Az adatok részletessége profilozó típusokban A profilerek, amelyek maguk is programok, elemzik a célprogramokat, és információkat gyűjtenek azok végrehajtásáról. Az adatok részletessége, az, hogy a profilozók hogyan gyűjtik az információkat, esemény-alapú vagy statisztikai profilokba sorolják őket. A profilkészítők megszakítják a program végrehajtását az információk gyűjtése érdekében, ami korlátozott felbontást eredményezhet az időmérésekben. Az alapvető blokk profilerek számos gépi óraszám-ciklust jelentenek, amelyek az egyes kódsorok végrehajtására vonatkoznak, vagy ezek összeadásán alapuló időzítést; az alapvető blokkonként jelentett időzítések nem tükrözik a gyorsítótár találatai és hiányosságai közötti különbséget.
Esemény alapú profilozók Az itt felsorolt programozási nyelvek eseményalapú profilozókkal rendelkeznek: Java: a JVMTI (JVM Tools Interface) API, korábban JVMPI (JVM Profiling Interface), horgokat biztosít a profilerek számára olyan események csapdájához, mint a hívások, a class-load, unload, thread enter leave. .NET: Profilozó ügynököt COM szerverként csatolhat a CLR-hez a Profiling API használatával. A Javához hasonlóan a runtime különféle visszahívásokat biztosít az ügynökbe olyan események csapdájához, mint a JIT / belépés / távozás, az objektum létrehozása stb., Különös tekintettel arra, hogy a profilozó ügynök tetszőleges módon átírhatja a cél alkalmazás bájtkódját. Python: A Python profilozása magában foglalja a profilmodult, a hotshotot (amely hívás-gráf alapú), és a 'sys.setprofile' függvényt használja az olyan események csapdájához, mint a c_{call,return,exception}, python _{call,return,exception}. Ruby: A Ruby is a Pythonhoz hasonló felületet használ a profilkészítéshez. Lapos profilozóval a profil.rb-ben, a modulban és a ruby-prof-ban egy C-kiterjesztés van jelen.
Statisztikai profilozók Néhány profilkészítő mintavétel útján működik. A mintavételi profilerek rendszeres időközönként tesztelik a célprogram hívásvermét az operációs rendszer megszakításokkal. A mintavételi profilok általában kevésbé pontosak és specifikusak numerikusan, de lehetővé teszik a célprogramnak a teljes sebesség közeli futtatását.
A kapott adat nem pontos, hanem statisztikai közelítés. „A tényleges hibamennyiség általában egynél több mintavételi periódust tartalmaz. Valójában, ha egy érték a mintavételi periódus n-szerese, akkor az abban várható hiba n mintavételi időszak négyzetgyöke.” Statistical Inaccuracy of gprof Output
A gyakorlatban a mintavételes profilerek gyakran pontosabb képet nyújtanak a célprogram végrehajtásáról, mint más megközelítések, mivel kevésbé támadják a célprogramot, és így nem járnak annyi mellékhatással (például a memória gyorsítótárain). Mivel ezek nem annyira érintik a végrehajtási sebességet, felismerhetnek olyan problémákat, amelyek egyébként rejtve maradnak. Relatív immunitásuk van a kicsi, gyakran hívott rutinok vagy „szűk” ciklusok költségeinek túlbecslésére is. Megmutathatják a felhasználói módban eltöltött idő és a megszakítható kernelmód közötti relatív időt.
Ennek ellenére a megszakítások kezelésére szolgáló kernelkód kisebb veszteségeket okoz a CPU ciklusokban, elterelte a gyorsítótár használatát, és nem képes megkülönböztetni a megszakíthatatlan kernelkódban fellépő különböző feladatokat (mikroszekundum-tartományú tevékenység).
A dedikált hardverek meghaladhatják ezt: az ARM Cortex-M3 és néhány újabb MIPS processzor JTAG interfésze rendelkezik egy PCSAMPLE regiszterrel, amely valóban észlelhetetlen módon veszi a programszámláló mintáját, lehetővé téve a lapos profil (flat profile) nem tolakodó begyűjtését.
Néhány általánosan használt statisztikai profilkészítő Java / kezelt kódhoz a SmartBear Software AQtime és a Microsoft CLR Profiler. Ezek a profilozók támogatják a natív kód profilozását, többek között az Apple Inc. Shark (OSX), OProfile (Linux), Intel VTune és Parallel Amplifier (az Intel Parallel Studio része) és az Oracle Performance Analyzer segítségével.
Instrumentáció Ez a technika hatékonyan hozzáadja az utasításokat a célprogramhoz a szükséges információk összegyűjtésére. Egy program instrumentálása teljesítményváltozásokat okozhat, és bizonyos esetekben pontatlan eredményekhez és / vagy heisenbug-okhoz vezethet. A hatás attól függ, hogy milyen információkat gyűjtenek, az időzített adatok részletezett szintjéről, és attól, hogy az alapvető blokk profilozást használják-e az instrumentálással együtt. Például, ha kódot ad hozzá minden eljárás / rutin hívás megszámolásához, akkor valószínűleg kisebb hatással lesz, mint az, ha megszámolja az egyes állítások teljesülését. Néhány számítógép rendelkezik speciális hardverrel az információk gyűjtésére; ebben az esetben a programra gyakorolt hatás minimális.
Az instrumentálás kulcsszerepet játszik a profilerek rendelkezésére álló ellenőrzési szint és az időfelbontás mennyiségének meghatározásában. Manuális: a programozó hajtja végre, pl. utasítások hozzáadásával a futási idő kifejezett kiszámításához, egyszerűen számoljon eseményeket vagy hívásokat mérési API-khoz, mint például az Application Response Measurement szabvány. Automatikus forrásszint: a instrumentálás hozzáadása a forráskódhoz egy automatikus eszközzel, egy beállított szabály szerint. Középnyelv: az assembly vagy a lefordított bytekódokhoz hozzáadott instrumentálás, amely támogat több magasabb szintű forrásnyelvet, és elkerüli a (nem szimbolikus) bináris offset újraírási problémákat. Fordítóprogrammal támogatott Bináris fordítás: az eszköz hozzáadja az instrumentálást egy összeállított végrehajtható fájlhoz. Futásidejű instrumentálás: közvetlenül a végrehajtás előtt a kód instrumentélva. A program futását az eszköz teljes mértékben felügyeli és irányítja. Futás közbeni beszúrás: könnyebb, mint a futásidejű instrumentálás. A kódot futási időben módosítják úgy, hogy ugrásaik legyenek a segítő funkciókhoz.
Interpreter instrumentálás Az interpreter hibakeresési opciók lehetővé teszik a teljesítménymutatók összegyűjtését, mivel az interpreter találkozik minden cél feltétellel. A bájtkód, a vezérlőtábla vagy a JIT interpreterek három példa, amelyek általában teljes mértékben ellenőrzik a célkód végrehajtását, ezáltal lehetővé téve a rendkívül átfogó adatgyűjtési lehetőségeket.
Hypervisor/szimulátor Hypervisor: Az adatokat az (általában) nem módosított program hypervisor alatt történő futtatásával gyűjtik. Példa: SIMMON