Method and system for debugging a program that includes declarative code and procedural code
US-9239773-B1 · Jan 19, 2016 · US
US9703681B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-9703681-B2 |
| Application number | US-201414444987-A |
| Country | US |
| Kind code | B2 |
| Filing date | Jul 28, 2014 |
| Priority date | May 29, 2014 |
| Publication date | Jul 11, 2017 |
| Grant date | Jul 11, 2017 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
Assistance is given to aid in optimizing a program's performance during initial development while the program's features are still being implemented and/or debugged, without interfering with that development, by providing easy-to-ignore yet accurate tips about a program's performance inside a debugger. Raw performance information for a software program which is being debugged in a debugger is adjusted by removing from it a measured debug overhead or other diagnostic overhead. Some factors considered when measuring overhead include pauses, context switches, debug versus release build presence, bounds checking, funceval, and call stack analyses. The debugger is enhanced to display the adjusted program performance measure in a graphical user interface, next to the corresponding source code. The enhanced debugger updates the adjusted program performance measure value and keeps its screen location current as the developer moves through the source code, providing more detailed performance information upon request.
Opening claim text (preview).
What is claimed is: 1. A computational process for use in software development, comprising: automatically obtaining raw performance information for a software program which is being debugged in a debugger which has a graphical user interface; automatically removing a measured diagnostic overhead from at least part of the raw performance information, thereby producing at least one adjusted program performance measure; and automatically displaying in the debugger graphical user interface a visual representation of the adjusted program performance measure and at least a number of lines of source code whose corresponding executable contributed most recently to the program performance that is measured by the adjusted program performance measure, the number being in the range from one to four. 2. The process of claim 1 , wherein the raw performance information includes a raw value for at least one of the following program performance measures: memory usage by a native code portion of the software program, memory usage by a managed code portion of the software program, memory usage by a particular processor, memory usage by a central processing unit, memory usage by a floating point processing unit, memory usage by a graphical processing unit, allocated heap memory usage, processor usage, central processing unit utilization, floating point processing unit utilization, graphical processing unit utilization, low-level processor events, cache misses, branch mis-predictions, pipeline stalls, read/write hazards, number of instructions executed, elapsed running time of application code, frame rate, thread activity, nonvolatile storage subsystem usage, network interface usage, electrical power usage, peripheral device usage, allocated resource usage, sampled uniformly weighted resource usage, or sampled proportionately weighted resource usage. 3. The process of claim 1 , further comprising providing updated visual representations of the adjusted program performance measure in a source code window of the debugger in response to execution of portions of the software program in the debugger. 4. The process of claim 1 , wherein removing a measured diagnostic overhead comprises at least one of the following: ascertaining a pause start time and a pause stop time indicating when execution of the software program was paused in the debugger, and removing paused time from a running time that is calculated for the software program; ascertaining a pause start time and a pause stop time indicating when execution of the software program was paused in the debugger, and removing usage of a computational resource during the paused time from a resource usage that is calculated for the software program; assigning a context switch count representing how many debug context switches occurred during an execution period of the software program in the debugger, and adjusting a raw program performance measure based on the context switch count; adjusting a raw program performance measure based on statistical information about debug build presence in at least a portion of the software program; adjusting a raw program performance measure based on statistical information about release build presence in at least a portion of the software program; adjusting a raw program performance measure based on array bound checking code presence in at least a portion of the software program; adjusting a raw program performance measure based on information about how many times functions in debug builds were called and information about how many times functions in release builds were called during execution of the software program; adjusting a raw program performance measure based on a calculated probability that a portion of the software program is a debug build rather than a release build; adjusting a raw program performance measure based on a calculated probability that a portion of the software program is a release build rather than a debug build; adjusting a raw program performance measure based on a call stack analysis which classifies a portion of the software program as a debug build; adjusting a raw program performance measure based on overhead from a diagnostic tool other than a debugger; adjusting a raw program performance measure based on debugger funceval overhead; or adjusting a raw program performance measure based on a call stack analysis which classifies a portion of the software program as a release build. 5. The process of claim 1 , wherein the displaying step displays a visual representation of the adjusted program performance measure for an executed portion of the software program, wherein a boundary of the executed portion corresponds with a line of source code text displayed in a source code window, and wherein at least a portion of the visual representation of the adjusted program performance measure is displayed in a display area which is within zero to three horizontal text lines' distance of the source code text. 6. The process of claim 1 , wherein the visual representation has a link to additional program performance information, and the process further comprises: receiving a selection of the visual representation by a user; and then displaying at least a portion of the additional program performance information. 7. The process of claim 6 , wherein receiving a selection of the visual representation comprises at least one of the following: determining that a user has clicked on the visual representation; determining that a user has touched the visual representation; determining that a user cursor is hovering over the visual representation; or determining that a user has selected the visual representation at least in part by using a keyboard. 8. The process of claim 1 , wherein the displaying step displays a visual representation of the adjusted program performance measure which is easily-ignored in that it has at least three of the following characteristics: the visual representation does not obscure or hide any of the software program's source code in the debugger unless the visual representation is selected; the visual representation does not obscure or hide any user interface control for starting or pausing execution of the software program in the debugger; the visual representation does not obscure or hide any user interface control for setting or clearing a breakpoint in the debugger; the visual representation displays text in a font size that is no larger than the font size used for displaying source code text in the debugger; the visual representation uses less than twenty characters of text per adjusted program performance measure unless the visual representation is selected to display additional information; selection of the visual representation is not required in order to start or pause execution of the software program in the debugger; or selection of the visual representation is not required in order to set or clear a breakpoint in the debugger. 9. A computer-readable storage medium configured with data and with instructions that when executed by at least one processor causes the processor(s) to perform a technical process for providing performance information during debugging of a software program, the process comprising the steps of: automatically obtaining raw performance information for a software program which is being debugged in a debugger which has a graphical user interface, wherein the raw performance information includes a raw value for at least one of the following program performance measures: memory usage by a native code portion of the software program, memory usage by a managed code portion of the software program, allocated heap memory usage, processor usage, thread activity, nonvolatile storage subsystem usage
Performance evaluation by tracing or monitoring · CPC title
for performance assessment · CPC title
Monitoring of software · CPC title
Debugging of software · CPC title
Physics · mapped topic
Related publications grouped by family.
Answers are generated from the same data shown on this page.