Re: Injecting trace code under GNAT

[wrostek <wolfgang.rostek@gmx.de>]

Thank you both for your quick feedback

...
> If it is about measuring relative performance of subprograms,
> 
> then one good approximation is kcachegrind.
> 
> (With compiler switch -fno-inline in particular).
No, it's about understanding the program flow.
I'm very much preferring tracing over debugging. 
Means instrumenting code with minor impact on runtime.

Of course this is bulk data and needs specific care.

As an example I trace simple IDs and only integer values
to shared memory and stream it to disk by another process.
All formatting is off-line. This way I can inject a fairly
huge number of traces by low runtime penalties. My personal
taste is to accept up to ~3% runtime increase but have
this trace all time available. This did help me a lot in the
past to speed up turn-around time for error analysis.

But I'm aware that this approach isn't accepted by everybody ;)   


> 
> 
> 
> If you can target the JVM using JGNAT, too, then this target
> 
> might allow injecting something.
Yes, in my Java days there was this nice API interface
to the JVM to hook methods in. 

> 
> 
> 
> The -fprofile* compiler switches might be interesting.


I will elaborate all your proposals.

Wolfgang R.