cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1999/10/17/12:42:03

From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: allegro gone missing?
Date: Sun, 17 Oct 1999 14:20:16 +0200
Organization: NetVision Israel
Message-ID: <Pine.SUN.3.91.991017141953.25053R-100000@is>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 991011122627 DOT 28307G-100000 AT is> <380282EA DOT 3E6A AT earthlink DOT net> <Pine DOT SUN DOT 3 DOT 91 DOT 991013114157 DOT 16702F-100000 AT is> <38063D49 DOT 12D7 AT earthlink DOT net>
NNTP-Posting-Host: is.elta.co.il
Mime-Version: 1.0
X-Trace: news.netvision.net.il 940162738 22831 199.203.121.2 (17 Oct 1999 12:18:58 GMT)
X-Complaints-To: abuse AT netvision DOT net DOT il
NNTP-Posting-Date: 17 Oct 1999 12:18:58 GMT
X-Sender: eliz AT is
In-Reply-To: <38063D49.12D7@earthlink.net>
Lines: 45
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Thu, 14 Oct 1999, Rez wrote:

> > Don't forget that CWSDPMI was written by a single engineer on his
> > spare time.  Given that, I think 10% of a performance hit, and then in
> > some specific cases only, is acceptable.
> 
> BSP is a naked textmode DOS app, very CPU-intensive but with very little
> display output (a spinner and a few lines of text). Is that of any
> significance wrt this case's 10% performance difference?

Even a program that does nothing except being parked in an idle loop
involves the DPMI server, since there's a timer tick every 55 msec,
which triggers a mode switch (to reflect the interrupt to its default
real-mode handler).

In addition, if the setup of the machine under the two DPMI servers
being compared is different, it might well be that the difference has
nothing to do with the DPMI server per se.  For example, if one
configuration runs the machine in V86 mode and the other in the true
real mode, the mode-switch overhead is *much* larger in the real-mode
setup, no matter what DPMI host is in use.

> BTW when I do any sort of performance testing, I always disable cache,
> because otherwise you don't really know what influence it had on the
> results.

If a program does lots of disk I/O, this is not a very good idea,
because the sluggish I/O operations can completely shadow the other
parts of code.  It is much better to test every program in the same
environment where it normally runs.  If the cache brings some
non-deterministic effects, run the test several time and average the
results.

> Also I wonder if cache could disguise some program faults. Frex, on my
> other boot setup, which has a cache, one program's config file directory
> entry gets corrupted when I start the program. I've found if I first
> copy the config file from one location to another, then start the
> program, the corruption does not occur. Presumably at that point it's
> snagging the config file from cache instead of from disk. 

Generally, such problems indicate that someone is deleting (or
renaming) the file and then reading from the (now invalid) handle.  In
this case, having data in the disk cache might indeed conceal the
problem, at least for small files.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019