[fpc-devel] internal profiler 2

[Jonas Maebe]

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


Jonas