How Puma Gathers Data

Stack Traces

A stack trace is a snapshot of the program's call/return stack. It is an ordered sequence of the procedures that are active when the sample is taken.

Puma considers a procedure to be active (on the stack) if control is within the procedure itself or in any of its descendants. When a procedure is active, Puma's later analysis will show that time is being spent in-or-under that procedure. When the program counter is in a procedure, Puma's analysis will show that time is being spent in-only that procedure.

Title not available highlights the procedures that are active when contractor is executing, and garage has called contractor.

If Puma takes a sample when contractor is executing, the stack trace returned looks this way:

   \main\garage\contractor

The last procedure in a stack trace is the currently executing procedure. The other procedures in the list are the executing procedure's ancestors.

Figure 3-2 Active Procedures

Statistical Information

Puma records statistical information concerning the program's resource use, including:

Data Files

Puma stores the samples it collects in a data file. You can have any number of data files, and any legal UNIX filename is acceptable.

By default, Puma names its data files DataSetnumber.puma and places them in the directory where Puma is executing. When invoked in graphical mode, Puma loads the data files that reside in the directory where it is executing and have the filename extension .puma. You can load other data files manually from within Puma.

To reduce the overhead cost of collecting data, Puma does not write data immediately upon collecting it. Instead, Puma stores data in memory and writes to a data file only when one of the following events occurs:

Sample Interval

The sample interval is the rate at which Puma takes data samples.

The sample interval refers to the amount of time that Puma allows the target program to run before suspending it, recording information, and updating the graphic display. The time spent recording and displaying a sample is considered overhead.

The greater the overhead, the longer it takes for a data-collection session to complete.

The phrase samples per second refers to refer the number of samples gathered per second that the target program has been allowed to run. The number of samples gathered by Puma per elapsed (real) second depends upon the amount of overhead Puma incurs between each sample.

Thus, the number of samples that Puma takes per elapsed (real) second depends on the following:

By default, the sample interval is 100, which means that Puma gathers a sample every 100 milliseconds of the target process execution time (at a rate of 10 samples per second). This interval is under user control.