|
==Data granularity in profiler types==
Profilers, which are also programs themselves, analyze target programs by collecting information on their execution. Based on their data granularity, on how profilers collect information, they are classified into event based or statistical profilers. Profilers interrupt program execution to collect information, which may result in a limited resolution in the time measurements, which should be taken with a grain of salt. [[Basic block]] profilers report a number of machine [[cycles per instruction|clock cycles]] devoted to executing each line of code, or a timing based on adding these together; the timings reported per basic block may not reflect a difference between [[CPU cache|cache]] hits and misses.<ref>{{cite web| work=OpenStax CNX Archive| title=Timing and Profiling - Basic Block Profilers| url=https://archive.cnx.org/contents/d29c016a-2960-4fc9-b431-9eda881a28f5@3/timing-and-profiling-basic-block-profilers#id6897344}}</ref><ref>{{cite journal| last1=Ball| first1=Thomas| last2=Larus| first2=James R.| work=ACM Transactions on Programming Languages and Systems (TOPLAS)| volume=16| issue=4| pages=1319-1360 | title=Optimally profiling and tracing programs| publisher=ACM Digital Library| year=1994| url=https://www.classes.cs.uchicago.edu/current/32001-1/papers/ball-larus-profiling.pdf}}</ref>
Profilers, which are also programs themselves, analyze target programs by collecting information on their execution. Based on their data granularity, on how profilers collect information, they are classified into event based
or statistical profilers. Since profilers interrupt program execution to collect information, they have a finite resolution
in the time measurements, which should be taken with a grain of salt.
===Event-based profilers===
Dedicated hardware can go beyond this: ARM Cortex-M3 and some recent MIPS processors JTAG interface have a PCSAMPLE register, which samples the [[program counter]] in a truly undetectable manner, allowing non-intrusive collection of a flat profile.
Some ofcommonly theused<ref>{{cite mostweb| commonlytitle=Popular usedC# Profilers| publisher=Gingtage| year=2014| url=http://www.ginktage.com/2014/10/popular-c-profilers/}}</ref> statistical profilers for Java/managed code are [[AMDSmartBear Software]]'s [[CodeAnalystAQtime]]<ref>{{cite web| work=AQTime 8 Reference| title=Sampling Profiler - Overview| publisher=SmartBear Software| year=2018| url=https://support.smartbear.com/viewarticle/54581/}}</ref> and [[Microsoft]]'s [[CLR Profiler]]<ref>{{cite web| work=Microsoft .NET Framework Unmanaged API Reference| last=Wenzal| first=Maira, et al.| title=Profiling Overview| publisher=Microsoft| year=2017| url=https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/profiling/profiling-overview#supported-features}}</ref>. Those profilers also support native code profiling, along with [[Apple Inc.]]'s [[Apple Developer Tools#Shark|Shark]] (OSX),<ref>{{cite web| work=[[Apple Developer Tools]]| title=Performance Tools| publisher=Apple, Inc.| year=2013| url=https://developer.apple.com/library/content/documentation/Performance/Conceptual/PerformanceOverview/PerformanceTools/PerformanceTools.html}}</ref> [[oprofileOProfile]] (Linux)<ref>{{citationcite neededweb|date work=August[[IBM DeveloperWorks]]| last1=Netto| first1=Zanella| last2=Arnold| first2=Ryan S.| title=Evaluate performance for Linux on Power| year=2012| url=https://www.ibm.com/developerworks/linux/library/l-evaluatelinuxonpower/}}</ref>, [[Intel]] [[VTune]] and Parallel Amplifier (part of [[Intel Parallel Studio]]), [[Oracle Corporation|Oracle]] [[Performance Analyzer]].<ref>{{cite conference |last1=Schmidl |first1=Dirk |first2=Christian |last2=Terboven |first3=Dieter |last3=an Mey |first4=Matthias S. |last4=Müller |title=Suitability of Performance Tools for OpenMP Task-Parallel Programs |conference=Proc. 7th Int'l Workshop on Parallel Tools for High Performance Computing |year=2013 |pages=25–37 |url=https://books.google.com/books?id=-I64BAAAQBAJ&pg=PA27&lpg=PA27}}</ref>
===Instrumentation ===
This technique effectively adds instructions to the target program to collect the required information. Note that [[instrumenting]] a program can cause performance changes, and may in some cases lead to inaccurate results and/or [[heisenbug]]s. The effect will depend on what information is being collected, and on the level of detailtiming requireddetails reported, and on whether basic block profiling is used in conjunction with instrumentation.<ref>{{cite journal| last1=Carleton| first1=Gary| last2=Kirkegaard| first2=Knud| last3=Sehr| first3=David| title=Profile-Guided Optimizations| publisher=[[Dr. Dobb's Journal]]| year=1998| url=http://www.drdobbs.com/profile-guided-optimizations/184410561}}</ref> For example, adding code to count every procedure/routine call will probably have less effect than counting how many times each statement is obeyed. A few computers have special hardware to collect information; in this case the impact on the program is minimal.
Instrumentation is key to determining the level of control and amount of time resolution available to the profilers.
| 