Re: [fpc-devel] FPProfiler

2018-02-19 Thread Ozz Nixon
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

Re: [fpc-devel] FPProfiler

2018-02-19 Thread Ondrej Pokorny
On 19.02.2018 10:25, Anton Shepelev wrote: 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

Re: [fpc-devel] FPProfiler

2018-02-19 Thread Anton Shepelev
I wrote: >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. -- Please, do not forward replies to the list to my e-mail. ___ fpc-devel

Re: [fpc-devel] FPProfiler

2018-02-19 Thread Anton Shepelev
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

Re: [fpc-devel] FPProfiler

2018-02-19 Thread Benito van der Zander
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