Date: Tue, 05 Jun 2001 06:27:03 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: April <awhite AT mail DOT rosecom DOT ca>
Message-Id: <9743-Tue05Jun2001062703+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp AT delorie DOT com
In-reply-to: <3B1C2662.A2575F0D@mail.rosecom.ca> (message from April on Mon,
	04 Jun 2001 20:22:58 -0400)
Subject: Re: gprof question
References:  <3B1C2662 DOT A2575F0D AT mail DOT rosecom DOT ca>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: April <awhite AT mail DOT rosecom DOT ca>
> Newsgroups: comp.os.msdos.djgpp
> Date: Mon, 04 Jun 2001 20:22:58 -0400
> 
> 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.

Bad idea: you are now tuning a program whose code is vastly different
from your actual production code.

It is better to profile the optimized program.  If you have lots of
inlined functions, you can have Gprof to report them anyway, if you
use some special compiler switch (I don't remember for the moment what
switches are those, but the GCC manual and/or the Gprof manual should
tell).

> 
> 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
>   3.04     38.22     1.44                             mcount
>   2.92     39.61     1.39  1708128     0.00     0.00  KeyGet
>   1.99     40.56     0.94   916869     0.00     0.00  NodeCopy
> 
> These results were from inserting 20000 random words into the btree.  I
> was quite impressed with the number of calls to KeyGet, but I was
> equally shocked by the amount of time reported for __dpmi_int.
> 
> info simply states:
> 
>     This function performs a software interrupt in real mode after
> filling
>     in *most* the registers from the given structure.
> 
> I realize that this is a very ambiguous question, but what generally
> causes these interrupts to fire?

See section 13.4 of the DJGPP FAQ list, it deals with this very issue.