delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/10/29/12:18:13

Date: Wed, 29 Oct 1997 19:14:49 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Fabrice ILPONSE <fabrice AT asim DOT lip6 DOT fr>
cc: djgpp news group <djgpp AT delorie DOT com>
Subject: Re: DJGPP SLOW ?
In-Reply-To: <345725AC.2781E494@trash.lip6.fr>
Message-ID: <Pine.SUN.3.91.971029190457.28347D-100000@is>
MIME-Version: 1.0

On Wed, 29 Oct 1997, Fabrice ILPONSE wrote:

> 	After having compared to code. First in BC 3.1 under protected mode
> (with my PM engine) and the ohter under djgpp. djgpp appears to be
> 100%-200% slower ! :|
> 
> So i am searching for the reason of this speed waste.

A good point to start is section 14.5 (in fact, all of Chapter 14) of the 
DJGPP FAQ list.  If you don't have the FAQ, you can get it as 
v2/faq210b.zip from the same place you get DJGPP.

If you already tried everything the FAQ says, please tell more about your 
program.  Your original message didn't even have a word about what the 
program does.  It is impossible to help you without knowing something 
about the program.

> So, due to my DPMI knowledge, i wonder if the go32 header of the
> executables is fast.

What do you mean by go32 header?  How can a header be fast or slow?

> I know that djgpp lib contains a high resolution timer routine.

Which one?  Does your program call any such high-resolution timer 
routine?  If not, they are not linked into your program, and this cannot 
be the reason for bad performance.

> For each
> tick i suppose that both DOS and DPMI tick handler are called. That
> means at each tick a PM to REAL or REAL to PM switch! :0
> 
> Can that be a reason for the djgpp waste of time?

I don't think so.  First, there are only 18 such ticks per second.  Any 
reasonable processor, even i386, will run circles around anything that 
happens only 18 times a second.

More significantly, your real-mode code also suffers from this slow-down 
if your machine installs a memory manager such as EMM386 or QEMM, because 
these also run DOS in V86 mode, where the interrupts incur similar 
overhead.

So I suggest you look elsewhere for the reason of this slow-down.

- Raw text -


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