Browse Prior Art Database

Enable Debuggers As an Objective Performance Measurement Tool for Software Development Cost Reduction

IP.com Disclosure Number: IPCOM000013726D
Original Publication Date: 2001-Apr-08
Included in the Prior Art Database: 2003-Jun-18
Document File: 5 page(s) / 52K

Publishing Venue

IBM

Abstract

Most people think of debugger as a tool to repair defects in their programs. However, one overlooked capability of a debugger is that it can be enabled as an objective performance measurement tool to reduce software product development cost. Currently in the market today, there are no tools available for the programmers to: 1. identify which algorithm has the best performance during the design phase for prototypes; 2. identify which section of code has performance degradation during the unit test, line item test phase within one component;

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 33% of the total text.

Page 1 of 5

  Enable Debuggers As an Objective Performance Measurement Tool for Software Development Cost Reduction

    Most people think of debugger as a tool to repair defects in their programs. However, one overlooked capability of a debugger is that it can be enabled as an objective performance measurement tool to reduce software product development cost. Currently in the market today, there are no tools available for the
programmers to:

1. identify which algorithm has the best performance during the design phase for prototypes;

2. identify which section of code has performance degradation during the unit test, line item test phase within one component;

3. identify which section of code has performance degradation across components in the product.

In general there are two kinds of data used to measure software performance:

1. execution time

2. path length.

    The execution time data is not an objective measurement because multiple factors can affect the outcome of the execution time, such as the hardware used, the I/O setup, etc., which is outside the control of the program code. The path length, defined as the number of machine instructions to execute from point A to point B, is a reliable method for performance measurement since it is counting the machine instructions within the software program itself and the factors outside
the control of the software are excluded.

    This invention focuses on using path length data as the unit of measurement for program code performance, the enablement of the gathering of such data for
programmer's use, and how it would reduce cost for software product development.

Large software products such as DB2 goes through the following product development cycle:

Design Phase

|

| DR0/DR1

| |

| V

| DR2

| |

| V

| DR3

|

V

Implementation(Coding) Phase

|

| I0

| |

| V

| I1

| |

| V

| I2

|

V

Testing Phase

|

| Development Departments :

| Unit Test

| |

| V

| Line Item Test

| |

| V

|

| Test Departments

| Function Verification Test

1

Page 2 of 5

| |

| V

| System Verification Test

| |

| V

| Product Verification Test

| |

| V

| Performance Measurement

|

V

Package & Beta

|

V

Product Ship

       Note that the performance measurement is done at the end of the development cycle. Should there be an unacceptable performance degradation, then the issue is brought to the development departments to pinpoint the cause and to seek remedy. The development departments will design a new algorithm, do the coding, etc., and the phases of developmentcycle are repeated. Note that the disadvantages associated with this approach are many:

1. The development programmers have no way of measuring the performance of certain algorithm created until the end of the product cycle when

the performance department does the measurement.

2. With a large product, it is hard to pinpoint the section of code in the component that is causing the degradation.

3. When the section of code causing the performance degradation is identified, the programmer has to redesign the algorithm;...