Management Summary
==================

There are 2 new areas of performance relevant to the 3.2 revision.  They
are 330/350 (first supported in 3.2) performance, and the new HFS file
system performance.

330/350
Pascal 3.2 appears to take advantage of all of the 330's enhanced
hardware performance, based on comparisons to 320 speed.  It does not
take advantage of all of the 350's hardware performance; its speed
appears to track the CPU clock speed (1.56 x 320 speed), but does not
fully follow the increased FlexBus speed gain.  This is mostly due to
data and stack alignment problems.  Given Workstation Pascal's nature as
a self-hosting system programming language, it is unlikely we can obtain
more FlexBus benefit without introducing major incompatibilities and
doing major rewrites of the system.  Speed of the 350 under PAWS is
about 1.5 - 1.6 times speed of the 320.

HFS
In general, HFS file I/O response is reasonably "crisp" for most
operations, as is usually expected in PAWS.  It is generally somewhat
slower than LIF on the same disc.  FILER "List" seems slower than it
should be, but is comparable to SRM speeds.  The slight slowness seems
an acceptable tradeoff for the other benefits of HFS to the user.  LIF
is still available in 3.2, and is fully compatible with 3.1.

Background and Detailed Results - HFS
=====================================

Performance evaluation of Pascal 3.2 HFS implementation was done by Jim
Tear in the RMBASIC group.  Jim used late QA revisions of 3.2 to do the
evaluation.  We know of no reason that these should perform significantly
differently from the final 3.2 version.

As Jim's memos indicate, HFS is generally somewhat slower than LIF on the
same medium; the difference seems to be small enough not to cause serious
frustration or loss of data logging capability. Note that LIF is still
available to all 3.2 users who prefer its tuning; we have not removed any
capability by supplying HFS, we've merely provided a richer feature mix.
As well, Larry Fenske and I, both on the project team, used HFS on a
day-to-day basis, and had adequate opportunity to compare its "feel" to
those of LIF and SRM, the other 2 major mass-storage organizations
available under PAWS. We can't complain.

From personal experience, the most frustrating slowdown is in the FILER
List operation.  This is a "simple" operation and is expected to go
fast.  It doesn't, due to hidden complexities in dealing with the HFS
file system.  The good news is that the speed is comparable to (albeit a
little slower than) the speed of relatively unloaded SRM using a similar
class of disc drive for its storage.

Jim's results are embodied in the following memos.

------------------------------------------------------------------------

FROM:  Jim Tear                  DATE:    July 23, 1987

TO:    John Schmidt              SUBJECT:  PWS/HFS Performance
       Scott Bayes
       Larry Fenske

My very preliminary results must be disregarded since I did not realize
that someone had changed the interleave on one of my test discs.  Thus I
was comparing interleave 1 HFS with interleave 5 LIF.

Using BASIC, I studied performance as a function of interleave.  On the
9133D, interleave 4 gave the best results for both LIF and HFS.
Interleave 4 gave roughly a 2-7 X speed improvement with LIF and 2-5 X
improvement for HFS when compared to interleave 1.  Interleave 4 was
used for all subsequent PWS tests.

I timed some filer operations with a stop watch.  I selected typical
operations such as listing a directory, copying a file, copying many
files, and removing many files.

As an arbitrary collection of files, I selected the BASIC 5.0 system and
binary files.  There were 41 files ranging in size from 256 bytes to
258,048 bytes and occupying a total of 948,736 bytes.

The files were copied from a RAM volume to an HFS volume and a LIF
volume on a 9133D.  The times and ratios are given below.

	Operation			LIF	  HFS		Ratio

	Copy all files from RAM		28 secs    38 secs  	1.36
	List all			  .54       4.87        9.02
	Remove all			 4.56	   16.43	3.60

I investigated the effects of file size and disc "fullness" on file
copying.  Copying a file to an HFS disc that was 80 per cent full was
about 36% slower than than copying to a 30% full disc.

The effect of file size on file copying is presented below.  
The times are given for copying from RAM to LIF or HFS.
	
	File size (bytes)       LIF             HFS           HFS/LIF	

	20,736			1.28 secs	1.21 secs	.95
	56,576		        1.42		1.41		.99
	95,232                  1.70		1.68		.99 
	258,048                 3.36		5.49	       1.63 

One should not conclude that HFS is faster for copying smaller files.
There is a large experimental error in timing small times with a stop
watch.  I would conclude that the performance is the same until files
get large.

Remember that even though LIF is faster, it has serious limitations:
non-hierarchical directory structure, contiguous allocation, and
non-extensible files.  HFS is much more typical of modern directory
formats than is LIF.

------------------------------------------------------------------

FROM:  Jim Tear                  DATE:    July 24, 1987

TO:    John Schmidt              SUBJECT:  PWS/HFS Performance
       Scott Bayes
       Larry Fenske

Here is the summary of my evaluation of the performance of HFS file
I/O:

- HFS is much slower than LIF for create, close, and purge.

- HFS is faster than LIF for sequential write.

- HFS and LIF are about the same for open, sequential read,
  random write, and random read.

- Preallocated HFS files are faster than allocate-as-you-go
  HFS files for write, close, and purge.

Selected comparisons are presented below.  The reads and writes were
sequential, 512 bytes at a time.

	Operation	Bytes		HFS/LIF

	rewrite		2048		  2.5
	write		2048		   .9
	close		2048		  2.0
	reset		2048		  1.0
	read		2048		  1.0
	purge		2048		  4.2

	rewrite		131072		  6.9
	write		131072		   .7
	close		131072		  2.2
	reset		131072		   .9
	read		131072		  1.0
	purge		131072		  6.9

Allocate-as-you-go files took about 2.1 times longer than preallocated
files for a rewrite-write-close sequence.

I see nothing here that we need to apologize for.  Create and purge are
much slower than LIF because these are rather trivial operations on LIF.
HFS's more flexible non-contiguous allocation and extensible files more
than make up for it's poor speed in storage allocation and deallocation.

There is no HFS performance penalty in the important read and write
categories.  Surprisingly, HFS is actually faster than LIF for
sequential writes.

------------------------------------------------------------------------

Scott Bayes
Pascal Workstation Version 3.2 Project
