Re: Ada.Execution_Time

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:8omvicFgm0U1@mid.individual.net...
...
>> That's probably enough for soft real-time systems anyway; and the 
>> facilities are useful for profiling and the like even without any strong 
>> connection to reality.
>
> I don't see how Ada.Execution_Time would be very useful for profiling. 
> While it could show you which tasks are CPU hogs, it does not resolve the 
> execution-time consumption to subprograms or subprogram parts, which I 
> think would be the important information for code redesigns aiming at 
> improving speed. Real profilers usually do give you subprogram-level or 
> even statement-level information.

I was thinking of "profiling" by hand, essentially by adding profiler calls 
to "interesting" points in the code. I have a number of packages which are 
designed for this purpose.

My experience with subprogram level profiling is that it often changes the 
results too much, as the overhead of profiling can be a lot more than the 
overhead of calling small subprograms (like the classic Getters/Setters). 
Perhaps it is just the way that we do it in Janus/Ada (by adding it to 
Enter_Walkback/Exit_Walkback calls that occur at the entrance and exit of 
every subprogram [unless turned off by compiler switch or pragma], which 
mean you don't have to recompile anything other than the main subprogram).

Instruction level profiling (which is used to provide statement profiling) 
is a statistical method, and that has its own problems (its possible to get 
into a situation where the program and profiler operate in sync, such that 
the profiler never sees the execution of some of the code). It's also 
impractical unless you have a very fast timer interrupt or a long time to 
run (machines have gotten too fast for the one I used to use -- it only gets 
a few hits before the compilations are finished...).

> Of course, a profiler that collects subprogram-level execution time (per 
> call, for example) but does not know about Ada task preemption will 
> probably produce wildly wrong results.

Right, and that is a problem with both my profiling packages and the 
Janus/Ada subprogram profiler. They both use Calendar.Clock, which is 
obviously oblivious to task switching. Ada.Execution_Time would be a major 
improvement in that respect.

                              Randy.

P.S. I think I owe you a compiler update. Did you read on our mailing list 
about the latest beta of Janus/Ada?