[fpc-devel] internal profiler 2

[Peter Vreman]

At 13:21 7-9-2006, you wrote:

>On 7 sep 2006, at 12:54, Aleš Katona wrote:
>
>>Today I tried to find the reason behind Lazarus GTK2 slowdowns by
>>using
>>profilers. After both failed me (callgrind crashed with stabs info
>>error
>
>Did you compile everything with either -gv or without debugging info?
>If you did, it's a bug in the compiler support for Valgrind.
>
>>and gprof reported things which didn't get called {writeln was in to
>>test}) I tought it might not be such a bad idea to make a simple
>>internal (ala -ghl style) profiler which would generate some sort of
>>binary info file (which could then be read by various front-ends)
>>
>>The idea behind fist instance I have is to do something like -Cr for
>>example. Put some code before and after every function/method call.
>
>That's basically what -gp does (but only at the beginning of a
>function afaik).
>
>>I'm asking if this is possible (even if you don't want it in normal
>>fpc)
>>without too much work. Eg: is is possible to take some code-generator
>>class, and find this "CALL" handler and somehow make it insert code
>>before and after without much fuzz?
>
>grep for cs_profile in the compiler sources. It needs cpu-specific
>support though (tcg.g_profilecode is empty), mainly because of the
>registers that need to be saved and the way you need to interface
>with the gprof library. If you just save/restore all volatile
>registers you can call any routine you want via tcg.g_profilecode.
>
>>Also, is it possible to do this using only pascal? (so all platforms
>>would work, eg: "insert this function before every CALL and this
>>function after every CALL" or is translation on ASM level required?
>>{and
>>thus each OS and platform would need translation and testing})
>
>tcg works at the assembler level and is at the same time cpu- independent.
>
>I don't see this specific feature being added to svn though. For
>that, something more generic would probably be desirable (maybe in
>the direction of aspect-oriented programming, with generic before/ 
>instead/after support and the ability to restrict the scope of such
>code to certain units/classes/class hierarchies/...) -- although I
>don't see that being added to the compiler any time soon either :)

If it needs to be added this more generic AOP is the best solution. 
AOP also allows easy tracing on the fly with start/end of procedure 
infos. We can add a switch that enables AOP code and adds something like:

procedure blahblah;
begin
   if assigned(aoplist) then
     process_aoplist(rtti_of_function,aop_begin)
   ...
   if assigned(aoplist) then
     process_aoplist(rtti_of_function,aop_end)
end;


The additions will be in the implicit init/final code blocks. This 
all can be added at node tree level and is platform independent.


Peter