Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!microsoft!gordonl
From: gordonl@microsoft.UUCP (Gordon LETWIN)
Newsgroups: comp.os.os2
Subject: Re: HPFS performance
Summary: another HPFS performance point
Message-ID: <52093@microsoft.UUCP>
Date: 8 Mar 90 00:51:59 GMT
References: <22705@unix.cis.pitt.edu>
Organization: Microsoft Corp., Redmond WA
Lines: 40


One more point to make about the relative performance of HPFS or any
other file system: remember that it's the speed of the *filesystem* which
is described as 30% to 400% faster, not especially the speed of the
application.  This is a pretty obvious point, but people often overlook it.
Obviously, a real life application spends a lot of time doing stuff besides
I/O.   Even when it appears to be "I/O bound" it's probably doing something
to process or prepare the data that it's reading or writing.
Even using a copy program may introduce additional extra overhead - perhaps
the program transfers the data within it's memory buffers, etc.
When we benchmarked file systems we used special programs that just did
file system operations.  There were significant gains with real programs like
RBASE and C-compilers, etc., but not 400%!

As I recall, the "30%" number comes from comparing HPFS and FAT simple
file operations like read and write of moderate sized transfers.  It's
hard to be much better than FAT here for moderate sized sequential I/O
because both systems just write the data out to the disk in a contiguous
hunk, there's not much to be improved.  HPFS works hard to keep files
contiguous and is very successful at it.  FAT tends to keep files contiguous
when there is only one file being written at one time because of the
FAT chain.  Also, the large allocation unit that FAT needs for large disks
is a waste of space, but it's a win on performance because it guarantees
local contiguity.  HPFS allocates on a sector basis but still maintains
a high degree of contiguity even when multiple files are being simultaneously
written.

The "400%" number comes from stuff like creating and deleting files - 
like the time it takes to create (say) three interpass files for a
compiler or something.  HPFS does particularly well at this, and FAT
does particularly poorly, thence a 4 to 1 performance difference.

None of our claimed results compare stuff like the relative performance of
creating the 10,001th file because of course FAT would be massacred.  There's
no point in generating outrageous but silly numbers to throw around; we just
say that it's "impractical" for FAT but can be done with undiminished 
performance with HPFS.

	Gordon Letwin
	Microsoft