Mail Archives: djgpp/1997/09/09/07:42:29
On Mon, 8 Sep 1997, Nate Eldredge wrote:
> Same as above, with Netware Lite's NLCACHEX in XMS memory, 1700K cache size.
> unzip: 2m56.32s
> cat: 0m06.38s
>
> Same system, Linux 2.0.29, 1.2GB Western Digital hard drive, e2fs file
> system, timing by bash `time' feature (`real' time value), times included a
> `sync' to make sure everything got written.
> (unzip -q djlsr201.zip; sync): Info-Zip 0m11.289s (really!)
> (cat 10meg >/dev/null; sync): 0m03.459s
>
> Same as above, 340 MB Western Digital hard drive, msdos (FAT) file system
> unzip: 0m22.821s
> find: 0m03.000s
> cat: 0m08.350s
>
> Well, draw your own conclusions.
I can only conclude that your DOS system is configured sub-optimally.
I cannot verify the times for `find', since I don't know how many
files and directories did it find, but here are the times for the rest
on my P166 with Maxtor 2GB hard disk:
unzip -qq djlsr201.zip 27.5s (really!)
cat 13meg > /dev/null 2s
the difference in the clock speed (my 166MHz against your 133) cannot
explain such a big performance gap. So the problem must be system
setup, most probably the disk cache (mine was 8MB SmartDrv with
delayed writes enabled).
It seems like the good-for-nothing FAT filesystem might be only
responsible for relatively small decrease in I/O speed, if any. (I'd
recheck that 11 seconds of unzip, if I were you: it might be
significantly slower for the first time a zip file is read, because
after that it is in the disk cache built into Linux.)
- Raw text -