Oppolzer - Informatik / Blog

CPU time measurements for individual statements are IMHO kind of useless, if you
are not a compiler writer or machine architect. To know about the CPU usage of
single statements, it is much easier to look at the instructions generated by
the compiler.

Much more useful is the measurement of larger pieces of codes or the
identification of "hot spots", where much CPU is consumed in little loops for
example, which are executed very often.

Two approaches:

a profiling tool like STROBE, which observes the running TCB etc. and looks over
a certain period of time, in which places of the code the PSW is running. So a
distribution of the CPU time consumed over the whole code is generated, for
example in 64 byte chunks granularity. This way it is possible to identify the
locations in your program where most CPU is consumed.

Another approach, which we use in a home grown tool:

at certain points in the application, we called system functions like TIMEUSED
to calculate the used CPU time for certain function calls. But this information
is not printed immediately but instead stored into memory buffers and printed
only at the end of the application, together with the number of executions etc.
(Of course, if you have hundreds of function points in your application, which
you want to measure, the handling of the memory buffer must be very fast - we
used self-balancing trees to organize the time values for the different function
points. And: it is necessary that the measurement activity can be activated from
outside - DD-Name etc. - so that no code change is necessary. On the other hand:
the CPU overhead for the test for the measurement activation has to be reduced
to the absolute minimum.)

This is done on some hundred testcases, together with the regression tests, and
over time you can see, if new versions of the application have performance
problems, compared to the prior version, and if so, you can act accordingly.
That is, we are monitoring the performance of the application, but not only at
the overall level, but also at the level of individual function points. If this
is done regularly, you have an early warning system for potential performance
problems in your application.

Kind regards

Bernd



Am Donnerstag, 8. März 2012 17:03 schrieben Sie:
> On 8 March 2012 10:17, P.F. wrote:
> > AFAIK there are no free tools or programs you can write which can measure
> > CPU time for each COBOL statement.  You need to use a software tool like
> > STROBE or CA-TRITUNE or one like them to get that kind of information.
>
> And presumably if COBOL has any sort of optimization at all, it will
> in many cases be difficult to assign consumed CPU time to particular
> statements.
>
> T.H.