Mail Archives: djgpp/1998/10/07/05:00:12
On Tue, 6 Oct 1998, tyoung wrote:
> I tried cprintf with no apparent difference. In fact redirecting stdout
> to nil ( "ric.exe testroth > nil" ) had little effect on timing.
If redirecting to the null device doesn't help, the problem is not
with screen I/O, so cprintf will have no effect. (Actually, I don't
believe the screen I/O could ever dramatically slow down DJGPP
programs, since the DJGPP's screen I/O with stdio functions is *very*
fast, unless you do something stupid like printing string a character
at a time.)
> I also ran with RAMDRIVE to minimize file IO times. The jobs ran in about
> half the time with RAMDRIVE as they did from disk.
Is that on DOS or in DOSEmu? The latter would have entirely different
results than the former, when you put everything into a RAMDRIVE.
It would be a very surprising result to see a program that runs on DOS
get only twofold speedup when disk I/O is replaced with memory moves,
like in case of the RAMDRIVE. If that is true (on a pure DOS system),
I would say that disk I/O is not your problem either, and would
suggest to look for the cause elsewhere. Maybe you are calling some
DOS/BIOS function other than disk I/O repeatedly?
> Disk IS used inefficiently, in that no attempt is made to save
> information from include'd files. The same file may be re-read and
> re-interpreted many times.
That's not what I meant by ``inefficiently''. Sequential reads should
not pose any problems like what you describe, especially when
everything is served from a RAMDRIVE. Repeatedly seeking into random
locations into the file, using file I/O instead of handling buffers in
memory--these were the things I had in mind.
> However, the same is true under Linux. Since
> it seems Linux caches file I/O more efficiently, this might account for
> the much faster times under Linux, but then I would expect the RAM disk
> to perform better than it did.
It *does* perform better than you see. Linux caching is better than
SmartDrv's, but not ten times faster, especially if SmartDrv is given
a lot of memory (say, 10MB) to play with. Less than two times slower
in disk-bound programs is my rule of thumb, for well-configured DOS
systems as opposed to Linux systems on the same hardware.
It seems that all clues point into a direction that is not file/screen
I/O, but rather something else. It's impossible to tell without
looking at the sources, but clearly something is going on behind the
scene here.
Does the program access many files for something other than just
reading them? For example, does it read directories (with `readdir')
or calls `stat' on a lot of files?
- Raw text -