[fpc-devel] FPProfiler

[Sven Barth]

On 19.02.2018 12:17, Ondrej Pokorny wrote:
> On 19.02.2018 11:14, Sven Barth via fpc-devel wrote:
>> Am 19.02.2018 11:01 schrieb "Ondrej Pokorny" <lazarus at kluug.net
>> <mailto:lazarus at kluug.net>>:
>>
>>     I agree with Simon here. It's a similar scenario like heaptrc. Why
>>     not to add a compiler parameter to include profiling info? That
>>     would be just great.
>>
>>
>> It's not the same scenario as heaptrc is entirely working in the RTL
>> without any compiler extension (aside from the -gh parameter).
> 
> First of all - if you read my sentence again I said it is a */similar/*
> scenario and not the */same/* scenario.
> 
> BUT: to be completely exact a small compiler extension comes with -gh as
> well and that you cannot achieve with the RTL - if
> http://wiki.freepascal.org/heaptrc is not wrong: /Note: Do not add the
> heaptrc unit manually. The heaptrc unit needs to be loaded before
> lineinfo and only the compiler can do that./

This is only true if you rely on "-gl". Nothing stops you from manually
adding the "lineinfo" or "lnfodwrf" unit while using e.g. "-gw2" (in
this case "lnfodwrf" needs to be used of course). Then you simply add
"heaptrc" before the line information unit and you're set... The only
difference will be that the compiler is also able to load those two
units before the "objpas" unit is loaded which you can't do manually,
but that doesn't change much regarding the capability of heaptrc to
detect memory leaks.

> 
> So yes, -gh injects the heaptrc unit in front of lineinfo and the
> profiling compiler parameter injects profiling code into every compiled
> procedure/method. Don't tell me you don't see any similarities here :)
> And yes, even the word "same" can be seen as valid here, if you like
> word games :)
> 
> Second: FPProfiler works already now entirely in the RTL without any
> compiler extension. Your above statement just doesn't make sense.

FPProfiler works *with* the RTL (and packages) to *modify* the source
and then calls the compiler. However from within the program itself you
can't modify your own source code and instead need to rely on the
compiler to insert suitable calls for you (like you showed below). This
nevertheless requires more changes to the compiler than adding a switch
that allows loading a specific unit before another specific one.

>> Profiling code however would require extensions to the compiler
>> whereby it would also need to handle exceptions correctly and such things.
> 
> Yes, I am again absolutely aware of this and I still believe it's
> possible and probably even not that hard to achieve. You just need to
> inject a try-finally block (= "handles exceptions correctly") around
> every procedure/function block:
> 
> procedure Test;
> begin
>   EnterProfiling('MyUnit.Test');
>   try
>     // <<< real code here
>   finally
>     LeaveProfiling('MyUnit.Test');
>   end;
> end;
> 
> Of course EnterProfiling and LeaveProfiling must be thread safe (every
> thread to be profiled separately) - and they even can be a part of the
> RTL, the same as heaptrc code is. EnterProfiling and LeaveProfiling must
> eat all intern exceptions - this is perfectly doable in the RTL.

Yes, the bulk of the code that does keeps track of the profiling can and
should be done in the RTL (or with a hookable approach so that 3rdparty
code can extend it), but without the compiler inserting the calls to
those functions you have nothing. The heaptrc and line information can
still be used without such compiler support, even if the compiler should
not generate debug information.

> All in all, in my eyes absolutely doable and a great and valid compiler
> extension. And again - very very similar scenario to heaptrc, if you
> don't like the word "same".

I didn't say anything *against* adding this to the compiler, I had the
idea myself some time ago to implement this, but what I'm sensitive
about is you comparing one feature with another and saying they are
similar when they are not.

Regards,
Sven