Date: Wed, 7 Oct 1998 12:00:01 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: tyoung cc: oti AT phys DOT uu DOT nl, nate AT cartsys DOT co DOT softserv DOT dynip DOT com, djgpp AT delorie DOT com Subject: Re: Slooooww Iooooo -- Please help. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com 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?