Message-ID:	<3822A1C4.73D19A86@mpx.com.au>
Date:	Fri, 05 Nov 1999 20:22:13 +1100
From:	infinity girl <entropic AT mpx DOT com DOT au>
X-Mailer:	Mozilla 4.5 [en] (Win95; I)
X-Accept-Language:	en
MIME-Version:	1.0
To:	djgpp AT delorie DOT com
Subject:	Re: mcount, and gprof
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 991104190849 DOT 15148E-100000 AT is>
Reply-To:	djgpp AT delorie DOT com

hey again :)

unforunately i have deleted the version files in the manifest directory,
but the version
of the FAQ that i have says it was last updated fr djgpp version 2.01

so i think i have v2.01, unless the FAQ wasn't updated fr 2.02?


> This says that the program runs just a few seconds, while you were
> talking about 30 minutes.  What am I missing?

it was definitely 20-30 minutes.
i assumed those seconds figures were adjusted to be the time it would
take if the
profiling code wasn't there.  It adds up to about the right amount of
time that the
program usually takes..4-5 seconds.  {I sed 11 seconds in a previous
post, but that was
with a larger file - i was confused because i swapped to a smaller file
because the profiling was taking too long).

but if those figures are supposed to be actual time, then there has to
be something wrong.

i have a 486DX2/66 cpu, and just compiled the program with the -pg
option (no debug info,
or optimisations). 

readBuf is 20 lines, but is not very complex at all.
it does involve calls to other functions however, especially when it
needs to read from
the file, which is only 1 in 128k calls.  other times it just has to do
some memory
copying.  at first i was using the library function 'bcopy', but i wrote
my own code
to do the copying, and things sped up.. my program went from spending
most of it's time
in __dpmi_int to readBuf.

it doesn't matter that much that the profiling takes so long..gives me
an excuse fr a 
break.  i should be studying anyway ;)
but i thought there must be a reason.. 


thanks,
daniel.

- Raw text -