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_______________________________________________
fpc-devel maillist  -  [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to