Visual program runtime performance analysis

Details Visual program runtime performance analysis Visual program runtime performance analysis

1998-09-16

2001-02-13

Chaki, Kakali (Department: 2762)

Data processing: software development, installation, and managem

Software program development tool

Translation of code

C717S152000, C702S186000, C714S035000, C714S038110, C714S039000, C714S047300, C345S215000, C345S215000, C345S215000, C345S960000

Reexamination Certificate

active

06189142

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to computer software, and deals more particularly with a method, system, and computer program for providing runtime performance analysis in a visual programming environment. A data collection technique is defined for performance monitoring and analysis in the visual programming environment. Information is gathered on the length of time required to execute visual programming elements, and on the number of times a particular visual programming element is executed.
DESCRIPTION OF THE RELATED ART
In evaluating and optimizing computer programs, it is desirable to obtain performance information from the actual execution of the program, such as information about the time required for executing different parts of the program, or the number of times specific parts of the code are executed. “Performance monitoring” is concerned with monitoring execution dynamics of the software under situations that simulate, as nearly as practical, the actual operating environment in which the software is intended to run. The data gathered during this monitoring, or tracing, are then analyzed to locate the corresponding places in the code that form bottlenecks. Analysis of the code can then be made, with the goal of changing the program in some way to remove the performance problem. Additionally, the data gathered during performance monitoring may indicate those places in the code where a significant amount of overall execution time occurred. The programmer can then analyze (and possibly modify) that code to ensure that it is performing acceptably.
Performance monitoring is often referred to equivalently as performance benchmarking or performance testing, because the execution that simulates the actual operating environment is a “test” of the program's execution characteristics. The analysis process may also be referred to as performance tuning, although performance tuning is a broader term which encompasses the notion of changing the code, or “tuning” it, in an attempt to improve performance. For ease of reference, the term “performance analysis” will be used hereinafter as a shorthand for “performance monitoring and analysis”, unless otherwise stated.
Performance analysis may focus on a number of different aspects of program execution. Some execution characteristics are user-oriented, while others are system-oriented. As an example of the former, response time may be measured, where the time that elapses between a user's request and the program's response to the user is calculated for the purpose of comparing it to what a user may consider “acceptable”. System-oriented characteristics are concerned with whether the system resources, such as the central processing unit and main storage, are being used in the most productive manner.
Many techniques and tools exist today for monitoring the execution dynamics of programs written using conventional programming languages. Two common techniques are: (1) tracing, which gathers data (e.g. elapsed execution time, and execution counters) each time a function (or procedure, equivalently) is called; and (2) profiling, which uses periodic sampling of the execution stack to determine an estimate of what percentage of the execution time was spent in a specific function (or how many times it was executed). Both of these techniques are concerned with conventional code elements. However, component-based visual programs are different from conventional programs in several important ways. Because of these differences, known performance monitoring and analysis techniques cannot be applied to this new programming domain in a way that provides meaningful results. (The term “visual program” is used herein as a shorthand for “component-based visual program”.)
A first difference between visual programs and conventional programs relates to the types of building blocks used by a programmer in creating a program, and a second difference lies in the source of those building blocks. Visual programs are graphically constructed primarily from pre-built components, equivalently referred to as “parts”, which are typically supplied (along with the code which implements those components) by the vendor of the visual programming environment (or by a third-party vendor of such parts). Examples of visual programming environments are VisualAge for Java and VisualAge Smalltalk, from the International Business Machines Corporation (“IBM”). VisualAge is a registered trademark of IBM, and Java is a trademark of Sun Microsystems, Inc. A conventional programmer, on the other hand, typically writes program code himself using textual source-code statements of a programming language such as the C language. The source code statements specify data definition, as well as all operations on the data that are required in order to achieve the desired end result. Alternatively, in an object-oriented programming environment, the object-oriented programmer writes programs in a programming language such as Smalltalk, by creating or re-using objects and methods. Because the object- oriented programmer writes programs using source language coding statements, object-oriented programming will be considered as a “conventional” programming environment for purposes of the present invention.
The visual programmer writes a program by selecting from the pre-built components (often by selecting visual representations of these components), and specifying how, and in what sequence, the selected components will interact. The visual programming environment software then generates executable code that creates runtime objects that will implement the specified interactions. This generated code is constructed by the visual programming environment, and the visual programmer may have no idea of the performance implications of invoking/using this code. Further, because this generated code is created automatically by the programming environment, the programmer may raise support and warranty issues by altering it for tuning performance. In addition, because visual programs are written using components and interactions, profiling information expressed in terms of the number of calls to various functions, or the amount of execution time spent in each, does not provide useful data to the visual programmer. And, if profiling information expressed in these terms indicates inefficiencies, there is no correlation to the components and/or interactions which are the ones needing performance tuning. Finally, showing the visual programmer performance data in terms of the underlying code requires him to work at a different level (i.e. generated text, using source code in a programming language such as C or Smalltalk) during performance analysis than that in which he worked while programming (i.e. visually, using parts and interactions), which may be confusing, error prone, and inefficient.
End-users often complain about the performance of programs written using visual programming development environments. One of the main reasons for performance problems in these programs is that the programmer is usually oblivious to the performance implications of the programs he creates. The visually-created program may perform, under the covers, actions that are time-consuming, and which could have been optimized (or avoided) if the programmer had known about them. Consultants are often called in to assist programmers in performance tuning of their visually-created applications, increasing the overall cost of those applications. Because tools adapted to the special characteristics of the visual programming environment are not currently available to these consultants, an inordinate amount of time is expended in the tuning process. By providing a technique that allows tracing and analyzing these visually-created programs, program performance can be improved effectively and efficiently, reducing the time and expense involved. This, along with the improved program performance, will greatly increase the acceptance of visually-created programs by end-users.
Accordingly, what is needed is a technique

Affiliated with

Also associated with

Rating

Visual program runtime performance analysis does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Visual program runtime performance analysis, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Visual program runtime performance analysis will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2562871