Why is not FPProfiler shipped as a binary with the standard FreePascal distribution? I belive many users would appreciate it, especially those using Windows (as I am), where the standard Unix utilities are not readily available and require effort to in- stall and configure.

Why does FPProfiler seem to depend on Lazarus?

Is it usable meanwhile? I think it was initially planned to be included in lazarus. But if it is worth to be included in FPC, we can do so.

Is it usable meanwhile? I think it was initially planned to be included in lazarus. But if it is worth to be included in FPC, we can do so.

There is a Lazarus package which can compile the project with profiling and provides some views to analyze the data.
I would appreciate the shipping with FPC, as this would remove the need of non-standard unit search paths.

However I think, FPC should generate the profiling code itself. Then there is no need to modify the code before and after the compilation.

Florian Klampfl to Anton Shepelev:

I have not tried it, but asked this question when I found it missing from the FreePascal distribution and requiring Lazarus to build. If it is as good as, or better than, gprof then it is certainly use- ful for me. The XML output format is an overhead for direct reading, so I should prefer an option for plain-text output. If it is ported to vanilla FPC, I may try to implement it myself.

I think it was initially planned to be included in lazarus. But if it is worth to be included in FPC, we can do so.

Please, do. Begin a generic tool, a profiler that need not be limited to a specific IDE.

Simon Ameis:

However I think, FPC should generate the profiling code itself. Then there is no need to modify the code before and after the compilation.

Not, I think, for the naive light-weight profiling that FPProfiler offers. Its functionality is easily decoupled from that of the compiler and I think should stay so, for better modularity.

Although more complicated and advanced profiling techniques may require close integration with the compiler, FPProfiler seems very good a small stand- alone appliation.

Begin a generic tool, a profiler that need not be limited to a specific IDE.

Correction:
Being a generic tool, a profiler need not be limited to a specific IDE.

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.

Ondrej

Am 19.02.2018 11:01 schrieb "Ondrej Pokorny" :

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). Profiling code however would require extensions to the compiler whereby it would also need to handle exceptions correctly and such things.

Regards,
Sven

Hi,

Sven Barth wrote

It's not the same scenario as heaptrc is entirely working in the RTL without any compiler extension (aside from the -gh parameter). Profiling code however would require extensions to the compiler whereby it would also need to handle exceptions correctly and such things.

Yes, but it's still worth thinking about how to generalize the current GNU Profiler support we have, which is messy at places, and of course entirely depends on GNU Profiler. But it's still mostly about generating a call to _mcount in various ways, taking the stackframe of various platform ABI into account. In theory a call to _mcount could be replaced with a compilerproc, which you could then override in the RTL, allowing a way to add support for various profilers.

I'm sure it would allow moving out some of the complexity from the compiler to the RTL, and make things more flexible in the end.

(And GNU profiler's _mcount itself also depends on GCC/GLibc implementation details per platform.)

Charlie

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./

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.

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.

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".

Ondrej

Hi,

In theory a call to _mcount could be replaced with a compilerproc, which you could then override in the RTL, allowing a way to add support for various profilers.

If it became fully overridable,  you could put a callback between any branch/line/function and create instrumentalization not just for profilers.

A single tracing system for gprof, gcov, american fuzzy lop, etc. ...

Best,
Benito

Just a friendly suggestion… You are close to how I did it in Modern Pascal:

procedure Test;
begin
  EnterProfiling('MyUnit.Test');
  try
    // <<< real code here
  finally
    LeaveProfiling('MyUnit.Test');
  end;
end;

In my profiler, I do not need a string for the Leaving Profiling, I use a Link-List Queue. My Enter Profiling Stores the procedure name, timestamp (nano) and when leaving, I track it in the Catcher app with elapsed time, etc. It uses a SQL Memory Dataset, allowing me to group etc. but, the primary point is optimizing the LeaveProfileing() to just a call.

Also, I do mine as {$IFDEF PROFILE_ON}EnterProfile(str); try{$ENDIF} {…original authors code…} {$IFDEF PROFILE_ON}Finally LeaveProfile; End;{$ENDIF}… this reduces an end to end code modification of my customers source. It’s a onetime modification, and I have checks to make sure nothing has been added w/o the wrapper… a simple sanity check. I would suggest incorporating this into FPC, like we have -Si, we could add –Sp, or since the S parameter is quite busy, putting into -P1 (Profiling Strategy 1).

Regards,

Ozz

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.

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.

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

You still didn't convince me that the two features aren't similar :) But no problem. I am glad you wanted to implement a built-in profiler yourself.

Ondrej