Mail Archives: djgpp/1999/06/21/09:48:22
Eli Zaretskii wrote:
> On Thu, 17 Jun 1999, Rolf Campbell wrote:
> > I suspect it's the windows DPMI stuff, and in general, all vm interupts.
> I would like to see some hard evidence before I believe in this. Most
> of the jobs I was talking about don't do anything of the above too
> much. They don't launch too many sub-programs, they don't call sbrk
> too much, and they certainly don't enable/disable interrupts.
It was just speculation..., but even text output uses interrupts. It being
buffered makes it more stable, but this could account for part of the difference.
I don't think it should have more than a +-7% effect <wild geuss>, but it should
have something.
> > When I ran it in real DOS with the same input file, it
> > always ended up taking the exact same amount of time. Under W95, not only
> > was it running at 10-30% slower, but it would vary greatly from one moment to
> > another. I would run it twice in a row, and one would be 9.8 seconds, the
> > other would be 7.6 seconds.
> This probably means that your DOS configuration didn't have any disk
> cache, or its cache was too small. I always get shorter times when I
> run a disk-bound program the second time, both in DOS and in Windows.
> Sometimes the difference is 10-fold, it really depends how large is
> the file that the program reads.
I was running without any disk-cache in DOS. And I understand how a program
can speed up under a cacheing system the 2nd time it runs, but I'm fairly
confident that the file i/o wasn't the bottle-neck (I profiled it). And it wasn't
just the first couple of times that it changed speeds, it was constantly changing
speeds under Win95 (the 10th time was distinctly different than the 11th and
12th).
--
-Rolf Campbell (39)3-6318
- Raw text -