To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: Less for DOS 
Date: Mon, 01 Aug 94 08:12:42 +0300
From: eliz AT is DOT elta DOT co DOT il

>                                 DJGPP provides a great
> enviroment for porting/developing memory hungry and cpu
> intenstive programs, but for file intensive programs, it just
> plain sucks.  Take a look at the port of the FSF fileutils:
> they're just plain slow.  Unless someone wanted to take the time
> to write a lowlevel 32bit interface to the hardware so that you
> don't have all those RM/PM switches, this isnt' going to change

I disagree.  It has been proven time and again that, if you use
a reasonable disk cache (even SmartDrive), on a 486DX, you don't
see the ``plainly sucking'' file I/O performance.  Even for fileutils
you have quite a decent performance.  I guess DJGPP's I/O could be
improved for large files by reading chunks of 32 or 64k bytes,
but hey, let's not forget we still have a 33-66MHz machine with
2-5 MBytes/sec disk system, so let's not judge it as we would
a 100MHz SGI machine with a SCSI-2 drive!

> Also I believe all of these packages use termlib rather than
> curses.  This means that termlib will have to be ported, and the
> user must use some sort of ansi.sys terminal interface.  I
> believe that these outputs will result in a RM/PM change for
> every screen update, so even that will be slow.
> 
> About the only possible way to make performance accetable to be
> to do some tremendous hacking of termlib:

That's the reason that I recommended the existing port of Less,
albeit not DJGPP-based, although I knew about Less v2.00 (and
I already use it on a Sun).  Those who happen to be addicted to
Less, will love that port, I think.  And no, Less is not so
disk intensive as it would seem: it's a file browser after all,
so you would expect it typically to sit and wait for the user
to read the page...

	Eli Zaretskii