From:	damon AT WRONG DOT redshift DOT com (Damon Casale)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: GPROF reports zero time spent?
Date:	Wed, 07 Mar 2001 22:54:18 GMT
Organization:	Posted via Supernews, http://www.supernews.com
Message-ID:	<3aa6b9b7.800087@news.redshift.com>
References:	<3aa69f21 DOT 386105 AT news DOT redshift DOT com> <9867vf$9ts$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE>
X-Newsreader:	Forte Free Agent 1.21/32.243
X-Complaints-To:	newsabuse AT supernews DOT com
Lines:	32
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

On 7 Mar 2001 21:07:59 GMT, Hans-Bernhard Broeker
<broeker AT physik DOT rwth-aachen DOT de> wrote:

>Damon Casale <damon AT wrong DOT redshift DOT com> wrote:
>> Hi, it's me again.  I'm trying to get gprof to profile my compression
>> program correctly, and it's driving me batty.  -_-
>
>> Here's the first few lines of (relevant) output:
>
>> Flat profile:
>
>> Each sample counts as 0.0555556 seconds.
>>   %   cumulative   self              self     total           
>>  time   seconds   seconds    calls  Ts/call  Ts/call  name    
>> 100.00    424.17   424.17                             __dpmi_int
>
>See the FAQ. In a nutshell: either you've hit a gprof bug, or your
>program is completely bottlenecked by I/O operations.

Hmm.  Apparently, I already have DJGPP v2.03.  So that can't be the
problem.

I know that other functions in my code take time.  I can turn off
compression, for instance, and make it go faster.  (There are over
200,000,000 calls to longest_match, one of the compression functions,
which gprof says takes no time at all.  That's completely untrue.)

I'm beginning to suspect that interrupts might have gotten turned off
somehow, or something like that.  I'll let everyone know...

Damon Casale, damon AT WRONG DOT redshift DOT com (remove the obvious)
S(E)TI not found.  There's no intelligent life here.

- Raw text -