Mail Archives: djgpp/1994/08/01/03:19:40
> 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
- Raw text -