Instrumentation (computer programming): Difference between revisions

Revision as of 23:07, 4 May 2020

Latest revision as of 11:02, 27 May 2025

(16 intermediate revisions by 14 users not shown)

Line 1:

{{Short description|Modification of software to allow for analysis}}

{{more footnotes|date=December 2013}}

In [[computer programming]], '''instrumentation''' is the act of modifying software so that [[analysis]] can be performed on it.<ref>A. Sabetta and H. Koziolek, “Measuring Performance Metrics: Techniques and Tools,” in Dependability metrics. Springer, 2008, pp. 226–232.</ref>

In the context of [[computer programming]], '''instrumentation''' refers to the measure of a product's performance, to diagnose errors, and to write [[Tracing (software)|trace]] information.<ref>[http://pic.dhe.ibm.com/infocenter/rtrthelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.rational.testrt.doc%2Ftopics%2Fcinstruovw.html Source Code Instrumentation Overview at IBM website]</ref> Programmers implement instrumentation in the form of code [[Instruction (computer science)|instructions]] that monitor specific components in a system (for example, instructions may output logging information to appear on the screen). When an application contains instrumentation code, it can be managed by using a management tool. Instrumentation is necessary to review the performance of the application. Instrumentation approaches can be of two types: source instrumentation and binary instrumentation.

Generally, instrumentation either modifies [[source code]] or [[binary code]]. Execution environments like the JVM provide separate interfaces to add instrumentation to program executions, such as the [[Java_Virtual_Machine_Tools_Interface|JVMTI]], which enables instrumentation during program start.

== Output ==

In programming, instrumentation means the ability of an application to incorporate:<ref>{{cite web|url=http://www.drdobbs.com/architecture-and-design/commenting-testing-and-instrumenting-cod/229300224|title=Commenting, Testing, and Instrumenting Code|date=January 3, 2011|accessdate=January 29, 2014}}</ref>

InInstrumentation programming, instrumentation means theenables ability[[profiling of(computer an application to incorporateprogramming)|profiling]]: <ref>{{cite web|url=http://www.drdobbs.com/architecture-and-design/commenting-testing-and-instrumenting-cod/229300224|title=Commenting, Testing, and Instrumenting Code|work=Dr. Dobb's |date=January 3, 2011|accessdate=January 29, 2014}}</ref>

* [[Profiling (computer programming)|Profiling]] - a means by whichmeasuring dynamic program behaviors can be measuredbehavior during a trainingtest run with a representative input. This is useful for properties of a program that cannot be [[static program analysis|analyzed statically]] with sufficient precision, such as [[software performance|performance]] and [[alias analysis]].

* Performance counters - components that allow the tracking of the performance of the application.

* [[Computer data logging]] - components that allow the logging and tracking of major events in the execution of the application.

Instrumentation can include:

* [[Tracing (software)|Logging events]] such as failures and operation start and end <ref>[http://pic.dhe.ibm.com/infocenter/rtrthelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.rational.testrt.doc%2Ftopics%2Fcinstruovw.html Source Code Instrumentation Overview at IBM website]</ref>

* Measuring and logging the duration of operations

== Limitations ==

Instrumentation is limited by execution coverage. If the program never reaches a particular point of execution, then instrumentation at that point collects no data. For instance, if a word processor application is instrumented, but the user never activates the print feature, then the instrumentation can say nothing about the routines which are used exclusively by the printing feature.

Instrumentation increases the execution time of a program. In some contexts, this increase might be dramatic and hence limit the application of instrumentation to debugging contexts. The instrumentation overhead differs depending on the used instrumentation technology.<ref>Reichelt, D. G., Bulej, L., Jung, R., & van Hoorn, A. (2024, May). Overhead Comparison of Instrumentation Frameworks. In Companion of the 15th ACM/SPEC International Conference on Performance Engineering (pp. 249-256).</ref>

Some types of instrumentation may cause a dramatic increase in execution time. This may limit the application of instrumentation to debugging contexts.

==See also==

* [[Hooking]] -– range of techniques used to alter or augment the behavior of an operating system, of applications, or of other software components either by intercepting function calls or messages or events passed between software components.

* [[Instruction set simulator]] -– simulation of all instructions at machine code level to provide instrumentation

* [[Runtime intelligence]] -– technologies, [[managed services]] and practices for the collection, integration, analysis, and presentation of application usage levels, patterns, and practices.

* [[Software performance analysis]] -– techniques to monitor code performance, including instrumentation.

* [[Hardware performance counter]]

* [[DTrace]] —– A comprehensive dynamic tracing framework for troubleshooting kernel and application problems on production systems in real time, implemented in [[Solaris (operating system)|Solaris]], [[macOS]], [[FreeBSD]], and many other platforms and products.

* [[Java Management Extensions|''Java Management Extensions'' (JMX)]] – Java technology for managing and monitoring applications, system objects, devices (such as printers), and service-oriented networks.

* [[Application Response Measurement]] -– standardized instrumentation [[Application programming interface|API]] for [[C (programming language)|C]] and [[Java (programming language)|Java]].

* [[Dynamic recompilation]] -– a feature of some emulators and virtual machines where the system may recompile some part of a program during execution.

==References==