Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3EA548ED.388F2546@phekda.freeserve.co.uk>
Date: Tue, 22 Apr 2003 14:51:41 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT elta DOT co DOT il>
CC: djgpp-workers AT delorie DOT com
Subject: Re: fstat, fd_props and inventing inodes, revision 3 [PATCH]
References: <E196rAk-0007Mp-00 AT phekda DOT freeserve DOT co DOT uk> <003101c30704$8dbb1ea0$0100a8c0 AT acp42g> <000a01c30708$aacbc680$0100a8c0 AT acp42g> <3EA2685E DOT 725043BC AT phekda DOT freeserve DOT co DOT uk> <8296-Sun20Apr2003135633+0300-eliz AT elta DOT co DOT il> <3EA2B7E2 DOT E83694EA AT phekda DOT freeserve DOT co DOT uk> <1858-Sun20Apr2003203205+0300-eliz AT elta DOT co DOT il> <3EA43D71 DOT F34E91EC AT phekda DOT freeserve DOT co DOT uk> <7443-Tue22Apr2003103725+0300-eliz AT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> > Date: Mon, 21 Apr 2003 19:50:25 +0100
> > From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
[snip]
> > > Btw, do we have any info on how long does it take for 5F46h to do its
> > > job on a typical system?
> >
> > Not very long! I add a one million iteration for loop executing
> > get_shares_internal (which calls Int 21h/5F46h) to the test program for
> > profiling. On my Athlon 850MHz running Windows '98 SE it sometimes took:
[snip]
> I'm not sure the time is linear with the number of iterations: Windows
> could do some kind of caching to hold the results of this lookup; if
> it does, the first call will account for most of the elapsed time.
> Can you see if the times are indeed linear with the number of
> iterations?

Well, I initially made the test do 1,000 iterations, but that took 0 seconds
according to the profile. So I made it do 1,000,000 iterations instead, to get
some significant results. I can't see how I can measure the time for the first
call, other than by running on a much slower computer, which I don't have.

It does seem to scale approximately linearly, but that's because it's spending
most (> 95%) of its time calling __dpmi_int.

I don't think the call takes long enough, to worry about it.

When I post the next version of the patch, perhaps someone with a slow
computer could try profiling it?

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]