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
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


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.