Times (in seconds) on a Macintosh LC with 40MB hard drive (access time 26 msec)
When not specifed, the times are with almost all INITs disabled
(there where only a couple which load themselves before the INIT manager
and SuperClock, which was used to measure speeds by subtracting the
initial and final times)

¥¥¥¥un-BinHex (ram disk -> hard disk, 900k file)

suntar 1.1  (.hqx.tar)  210 sec (the slowest unBinHexer in the world...)
deHQX 2.0				150 sec  (ram-ram) 175 sec (HD->HD) 
Stuffit 1.5.1		146 sec
suntar 1.2.1		 137 sec			(I carefully optimized the algorithm, but unfortunately
								that was not the bottleneck)
Stuffit Deluxe 3.0.6	125 sec
Downline	1.1	 125 sec
BinHex 4.0			  90 sec
Compact Pro 1.3.3	49 sec (with or without INITs: no event handling, no background
							operation, the Macintosh does nothing else until the extraction
							finishes: I never liked this way to speed up an application)
suntar 1.3.3		43 sec (48 with INITs)	(introduced disk buffering, and the
						optimizations introduced in 1.2 may now show their strength)
BinHqx DA (32k buffer size)		36 sec (38 with INITs)
suntar 2.0			33 sec	(36 with INITs)   	(uses a look-up table to compute the
										CRC error checking: pole position !!!)
								
¥¥¥¥compressed PackIt extraction (ram disk -> hard disk, 900k file)

PackIt III					315 sec (320 sec with INITs)
suntar 1.2.1      156 sec  (175 sec with INITs)
Stuffit Deluxe 3  130 sec
Stuffit 1.5.1		120 sec
unpit 0.1					105 sec
unpit 0.3 (compiled with Think C 5, I had the source but could not find the application)
                  100 sec
suntar 1.3.3      88 sec		(no change to the algorithm, but benefits from I/O buffering)
suntar 2.0 beta 8   66 sec	(uhh, in suntar 1.3 I'd forgotten to fully enable buffering !
							And obviously the faster CRC routine helps)
suntar 2.0        42 sec	(optimized the routine: it's not nice being
							proud of something which I knew was not the
							best I could do)

¥¥¥¥non-compressed PackIt extraction (ram disk -> hard disk, 900k file)

PackIt III			 225 sec
suntar 1.2.1   100 sec
StuffIt 1.5.1   65 sec
StuffIt Deluxe 65 sec
suntar 1.3.3    40 sec
unpit 0.1				29 sec
unpit 0.3				28 sec
Downline       23 sec
suntar 2.0 b8  18 sec       (the gain from 1.3.3 to 2.0 b8 is 22 sec: same file, same gain)
suntar 2.0     12 sec

¥¥¥¥tar extraction (floppy disk->ram disk, a directory with many files,
    end of archive at sector 2556)

suntar 1.1      140 sec  (187 with INITs)
suntar 1.2.1   140 sec  (185)
StuffIt Deluxe (.tar file on a HFS floppy)  75 sec (+16 for reading
	the directory + the time to select all the files in the scrolling list)
tar 3.0				51 sec     (59)
suntar 2.0   51 sec     (58)		(the accuracy of measurements can't guarantee a
									1 sec difference but suntar 2.0 performs some tests
									to identify long pathnames and it is reasonable
									to expect a small speed decrement over 1.3.3)
suntar 1.3.3 50 sec		(56)

(suntar 2.0: save sectors 0 to 2556 36 sec, Copy disk archive to file 47 sec)

¥¥¥¥tar extraction (file on hard disk->ram disk, 2556 sectors archive)

suntar 1.1   96 sec   (138 sec with INITs)
suntar 1.2.1 92 sec	  (135 sec)
StuffIt Deluxe 3.0.6   30 sec (33 with INITs) (+5 to read the directory)
suntar 1.3.3 22 sec		(28)
suntar 2.0   22 sec     (27)
tar 3.0      18 sec     (21)

¥¥¥¥tar extraction (HD->HD, 900k file)

suntar 1.1       92 sec
suntar 1.2.1    90 sec
untar 1.0         60 sec	(it's a new program and I did not perform other tests on it)
StuffIt Deluxe  21 sec
suntar 1.3.3    17 sec
suntar 2.0      17 sec
tar 3.0         12 sec

¥¥¥¥uudecode (ram disk -> hard disk, 900k file)

uulite 1.3		  300 sec	(what a pity, its user interface is very pretty, but 5 minutesÉ)
UMCPª Tools		  95 sec
tiger             65 sec (ram->ram)  120 sec (HD->HD)
un*files (bug fixed and recompiled with ThC 4)   55 sec (ram->ram) 105 sec (HD->HD)
StuffIt Deluxe    46 sec
suntar 2.0        30 sec
UUParser 1.5	  23 sec	(HD->RAM, I could not succeed to decode RAM->HD)
UUtool 2.32       20 sec

¥¥¥¥Macbinary extraction (HD->HD, 900k file)

UMCPª Tools	100 sec
suntar 1.2.1		96 sec
BinHex 5.0      29 sec
StuffIt Deluxe  24 sec
MacBinary II+   17 sec
suntar 1.3.3    17 sec
suntar 2.0      17 sec
suntar 2.0 (doubling the buffers size) 14 sec
MacBinary 1.01  12 sec

¥¥¥¥tar creation (HD->ram disk, 700k directory)

StuffIt Deluxe  28 sec
suntar 2.0      24 sec
tar 3.0         21 sec

¥¥¥¥tar creation (HD->HD, 900k file)

StuffIt Deluxe  17 sec
suntar 2.0      16 sec
tar 3.0         12 sec

¥¥¥¥tar creation (HD->floppy disk, 700k directory)

suntar 1.1     400 sec
suntar 1.2.1   360 sec
StuffIt Deluxe  (file on a Mac floppy disk) 125 sec
tar 3.0        49 sec
suntar 1.3.3   45 sec		(was buffered only towards the floppy)
suntar 2.0     42 sec

¥¥¥¥BinHex creation (HD->ram, 900k file)

StuffIt 1.5.1  128 sec
StuffIt Deluxe 110 sec
Downline       95 sec
BinHex 4.0     92 sec
BinHqx DA      51 sec
Compact Pro	47 sec
suntar 2.0      29 sec

¥¥¥¥MacBinary creation (HD->HD, 900k file)

UMCPª Tools     100 sec
suntar 2.0 b8   35 sec				(buffered towards the destination but not the source)
BinHex 5.0      29 sec
StuffIt Deluxe  26 sec
MacBinary II+   17 sec
suntar 2.0      15 sec
MacBinary 1.01  13 sec

If you are a programmer and you want to write fast code, this is what
I learnt in the process of speeding up suntar:

1) I/O buffering is always essential: I believe that in many categories
   the faster is the program which uses the largest buffer. The large
   jumps in the times (e.g. a factor of 2) between two programs are always
   due to different buffering schemes (e.g.: read one char at a time,
   512 bytes, 8k or more). But there is a point at which increasing the
   buffer gets no increase in speed, which depends on the device: for a
   hard disk 8k is good,  for a floppy disk it's better 9k (that's a
   track or half track on 720k or 1440k floppy disks), and very large
   buffers are still useful for an extraction to the same device if
   the source file and the destination file are placed at different
   positions and a large head movement is required every time the
   application loads or flushes a buffer.
2) only for complex conversions, at least for operations on fast disks,
   it's important a well optimazed algorithm, where most operations
   are done inside a single loop within a single function, with all
   essential variables kept in registers.
3) for very simple formats (MacBinary, non-compressed PackIt, tar)
   it's important to handle one format only: suntar suffers from its
   number of supported formats, StuffIt Deluxe suffers even more
   (I mean that it's possible and easy to be 50% faster than suntar
   in uncompressed PackIt extraction, no program does that only
   because the PackIt format is obsolete and the original
   PackIt is outperformed anyway also by non-optimized programs).
4) only if the algorithm should contain some code written by a
   Mathematician, some knowledge of Mathematics is not bad
   (Mathematicians usually write straighforwardly and never worry
   about speed, but in order to rewrite their code you must understand
   what they're doing).
5) assembly language is useful, but only in special cases: e.g. mcopy
   is three times faster than a standard memcpy, but it would be almost
   as fast written in C: it's the smart algorithm which makes it fast.
   Assembly language is really essential only if you need instructions
   which the C compiler does not exploit (DBRA, SWAP, BTST, all the
   operations involving the processor flags) or exceptionally when you
   need more register variables than the compiler supports.
6) never forget to measure the speed and compare it to other programs:
   one may believe to have written a wonderfully fast program and then
   discover that a small detail makes it slow.

							17 October 1993
							Gabriele Speranza