Today I tried to find the reason behind Lazarus GTK2 slowdowns by using profilers. After both failed me (callgrind crashed with stabs info error 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.

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?

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})

I know it's more complicated than this, but if there's some usable interface I could use to the CG I might give it a shot.

Ales

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

Ensure that you compile _everything_ with -gv only. No -g, no -gl.

Ensure that you compile _everything_ with -gv only. No -g, no -gl. _

yes I just did but now I get an exception in forms.pp (only if callgrind ./project1, running standalone works)

Generaly tho, we don't have an all-platform profiler.

Ales

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.

That's basically what -gp does (but only at the beginning of a function afaik).

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.

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 :)

Jonas

Aleš Katona wrote

Generaly tho, we don't have an all-platform profiler.

The problem with implementing this in the compiler is that it only works for code you compiled with such support in it. It won't work for the RTL we ship (unless we start shipping two version of the RTL, like there are also special profile-enabled versions of libc), nor for external libraries. It would be useful, but limited.

That's why most profilers don't rely on the compiler to do the work but either instrument (e.g. callgrind/valgrind) or sample (e.g. Shark on Mac OS X, or qprof which should work on pretty much any *nix out there).

Jonas

Jonas Maebe wrote:

I think it's more something which must be added to the implicit init/final code generation.

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

This looks promising. I'll look at the code when I get some free time and see if I'm able to do anything in this department.

Ales

gen_entry_code() and gen_exit_code(). The current code for gprof (enabled by the cs_profile switch) is also there. So for profiling this is also the correct position.

Peter