Date:	Sun, 20 Jun 1999 10:43:13 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Rolf Campbell <cp1v45 AT nortelnetworks DOT com>
cc:	djgpp AT delorie DOT com
Subject:	Re: [AL] Compilers comparisson, some opinions about the generated , assembler
In-Reply-To:	<37691E54.7ACB94D6@americasm01.nt.com>
Message-ID:	<Pine.SUN.3.91.990620104256.16821G-100000@is>
MIME-Version:	1.0
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, 17 Jun 1999, Rolf Campbell wrote:

>     I suspect it's the windows DPMI stuff, and in general, all vm interupts.
> Process creation/memory allocation (behind sbrk)/interupt
> enabling/disabling,.... it all adds up.

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.

> 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.

- Raw text -