Hi all, I have a relatively large FPC program that I suspect have a few bottlenecks (regarding processing speed). Are there any ways I can test how long time the program spends in the different procedures/functions?

Best regards Preben

Preben Mikael Bohn wrote

Hi all, I have a relatively large FPC program that I suspect have a few bottlenecks (regarding processing speed). Are there any ways I can test how long time the program spends in the different procedures/functions?

Use this bit of code in your functions/procedures or write it as a function and call it.

Hello,

Preben Mikael Bohn wrote

Hi all, I have a relatively large FPC program that I suspect have a few bottlenecks (regarding processing speed). Are there any ways I can test how long time the program spends in the different procedures/functions?

Use the -pg to compile your program and then use gprof to see profile information.

Best regards,
Adam Naumowicz

====================================================================== Department of Applied Logic fax. +48 (85) 745-7662 Institute of Computer Science tel. +48 (85) 745-7559 (office) University of Bialystok e-mail:
Sosnowa 64, 15-887 Bialystok, Poland http://math.uwb.edu.pl/~adamn/ ======================================================================

Hi all, I have a relatively large FPC program that I suspect have a few bottlenecks (regarding processing speed). Are there any ways I can test how long time the program spends in the different procedures/functions?

If the platform is suitable: read in the manual about profiling support and use the -pg switch.

2 choices, use profiling (see Marco's response), which is ok but a bit cumbersome IMHO, or add your own timing (this is what I do). I use clock from Tomas Schatzl's cpu unit which works for most o/s and also different pascals eg vpasc, fpc etc (1 microsec accuracy) and put in timing statements in the code, with a compiler conditional eg

uses cpu;
...
t:=clock;
...stuff to be timed....
{$ifdef time_it writeln('time to here=',clock-t); {$endif}

I then move the timing statement(s) until I find the bottleneck- usually pretty easy & then look at the code, change & retime...

Regards John

Hi all, I have a relatively large FPC program that I suspect have a few bottlenecks (regarding processing speed). Are there any ways I can test how long time the program spends in the different procedures/functions?

Best regards Preben

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

2 choices, use profiling (see Marco's response), which is ok but a bit cumbersome IMHO, or add your own timing (this is what I do). I use clock

The easiest will be in the future to use valgrind and kcachegrind. Those programs are linux-x86 only, but you don't need to recompile your program to get the an easy to browse profile.

I've some patches for valgrind 1.9.3 that will fix the incompatibilities with fpc. I already got the fpc compiling itself running under valgrind so most other fpc compiled programs should also work.

Peter

Hi,

well, I read something interesting here so I thought I could write a few lines. Since I don't have the previous mails anymore and the maillist archives (http://lists.freepascal.org/mailman/listinfo/fpc-pascal ?) don't seem to work I hope I'm not missing the discussion point way too much...

Valgrind sounds to be an interesting tool for detecting memory debugging. Otoh I am not really convinced about its use of a profiler (I've heard about it for the first time too). Isn't it the case that val/kcachegrind measures cache misses/hits on pre-processed code (e.g. x86 code transformed into an intermediate language, optimized and transformed back) according to a simulated cache model (which might not represent the actual cache model used by the processor properly)? Doesn't it act as a virtual P54C processor to the host program which do influence the program flow (e.g. use of specialized routines)?
It doesn't seem to profile the actual instructions as they are issued on the processor the way they were omitted by the compiler, so anyone knows how close to "real world" are those values really?
[I do guess it returns lots of nice numbers and with those you can always draw really nice looking graphs >:-]

I guess cachegrind does get the "big picture" about memory accesses but somehow I've my doubts about this method being really useful as a profiler, especially with the JIT compiler/optimization stage involved. I know a little (not much though) that other techniques have their drawbacks as well. Anyone knows whether somebody else ever had similar thoughts?

Probably my thoughts are completely without reason because as already mentioned I've heard about this program for the first time. Additionally my only source is the "The design and implementation of Valgrind"-doc, which is a little older (according to the 1.0.4 release, 1.9.x is current) so please bear with my foolishness.... ;-) Probably everything has been resolved in the "bazillions of other minor changes" on the webpage (http://developer.kde.org/~sewardj/)

Just interested and probably one of you can point me to resources without a close examination of the source...

Regards,
Thomas

The compiler does not insert very exotic instructions in the code so i guess that the results are close to the "real world". Maybe the visualization program kcachegrind can also read gprof output files in the future and then you can also visualize that output.

I also don't know much about the valgrind internals and how close it is to the real world. But i know from work were we needed to profile a multithreaded program that valgrind was one of the best options to use, gprof didn't give a good result.

Peter