From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: gprof question Date: 5 Jun 2001 10:33:51 GMT Organization: Aachen University of Technology (RWTH) Lines: 34 Message-ID: <9ficif$pi8$1@nets3.rz.RWTH-Aachen.DE> References: <3B1C2662 DOT A2575F0D AT mail DOT rosecom DOT ca> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 991737231 26184 137.226.32.75 (5 Jun 2001 10:33:51 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 5 Jun 2001 10:33:51 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com April 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.