Message-ID: <342F4975.40CE@EnchantedLearning.com>
Date: Sun, 28 Sep 1997 23:23:49 -0700
From: Mitchell Spector <spector AT EnchantedLearning DOT com>
Reply-To: spector AT EnchantedLearning DOT com
Organization: Enchanted Learning Software
MIME-Version: 1.0
To: djgpp AT delorie DOT com, Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>,
        Robert Hoehne <Robert DOT Hoehne AT Mathematik DOT TU-Chemnitz DOT DE>,
        "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT 2alpha DOT com>
Subject: Re: Clipboard timing, strange results, Rhide (Was: DJGPP,
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Eli Zaretskii wrote:
> 
> On Thu, 25 Sep 1997, Salvador Eduardo Tropea (SET) wrote:
> 
> > In plain DOS the effect is the reverse. RHIDE slows down the programs, or at
> > list the timing routines seems to indicate that. My plasmas run slower from
> > RHIDE and the meassured time is less stable than trying from
> > DOS. Why? I don't know.
> 
> I have asked this before on this thread, but didn't see any answers,
> so I will ask again: doesn't RHIDE hook the timer inetrrupt?  If it
> does, and if it doesn't unhook it when running child programs, then
> this might explain the behavior on DOS (an extra level of interrupt
> handling).  And Windows might change its scheduling of a program that
> has hooked the timer.

   This seems to be a peculiarity of the WINOLDAP interrupts.
There are really two problems here, presumably related: (1) the
excruciatingly slow speed of the interrupts (about 1/50 sec under
normal execution, perhaps 1/800 sec under Rhide), and (2) the
difference in speed between normal execution and execution under
Rhide (and in some other circumstances as well, as Robert Hoehne
pointed out).

   I tried replacing the clipboard interrupts in the timing code
I posted a few days ago with some other interrupts, to gauge the
effect.  The speeds I'm reporting are under normal execution in a
DOS box, on a 16 MB 133-MHz Pentium.  Here's what I found.  The
interrupt which just checks the WINOLDAP version number took
1/100 sec (which, needless to say, is very slow for something
that apparently just checks a version number!).  But the interrupt
which gets the current video mode took about 1/40,000 sec.  Also, the
Windows interrupt which gets the current Windows enhanced mode
version took about 1/40,000 sec.

   My conclusion is that the 1/40,000 sec timing represents
the overhead in DPMI interrupt handling.  The extremely slow
speed on the order of 1/100 sec only crops up in the WINOLDAP
interrupts, at least of the interrupts I've tried.  Since it
even happens in the WINOLDAP version check, I wonder if Microsoft
is going to disk every time to retrieve necessary code or data to
support the WINOLDAP interrupts?

   I'm not sure it's worth much more time trying to figure out
exactly what is happening here; the bottom line is that the
WINOLDAP interrupts are simply too slow to be useful in any
performance-sensitive situation.

   Thanks for everybody's ideas and suggestions.

Mitchell
--
Mitchell Spector, Enchanted Learning Software
E-mail: spector AT EnchantedLearning DOT com
Visit Enchanted Learning Software's web site for children!
-- http://www.EnchantedLearning.com --