Mail Archives: djgpp/2001/06/05/06:45:06
April <awhite AT mail DOT rosecom DOT ca> wrote:
> I've started trying to improve my program - a btree program - using the
> output of gprof.
> I compiled the program without optimization - I learned that hard
> way that functions inlined were not reported.
As Eli already said, this is a bad idea. Optimization changes the
timing behaviour of your program significantly, so you can't usually
optimize the non-compiler-optimized code by profiling and expect the
same effects on the compiler-optimized code.
To get profiling data for inlined functions, too, you should compile
with '-gstabs+ -pg' (or -ggdb instead of -gstabs+). Then you can run
'gprof -l' to profile at the single source line level. Only in this
mode you'll get adequate timing for inline function calls (but still
no execution counts).
> This is the top of the output of gprof:
> % cumulative self self total
> time seconds seconds calls ms/call ms/call name
> 65.73 31.22 31.22 __dpmi_int
> 11.70 36.78 5.56 __dj_movedata
This means that your code is entirely I/O bottlenecked. For a database
application, that's partly expected behaviour. What this trace tells
you is that the program spent two thirds of total run time waiting for
OS calls to complete, most of which are likely to be disk read and
write operations.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -