Mail Archives: djgpp/1999/10/17/12:42:03
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 -