Path: utzoo!attcan!uunet!peregrine!elroy!ames!mailrus!cornell!uw-beaver!uw-june!jmaloney
From: jmaloney@june.cs.washington.edu (John Maloney)
Newsgroups: comp.lang.smalltalk
Subject: Smalltalk and C: A Case Study
Message-ID: <5797@june.cs.washington.edu>
Date: 21 Sep 88 20:52:57 GMT
Organization: U of Washington, Computer Science, Seattle
Lines: 69

There has been some recent discussion of Smalltalk performance in
this forum recently. I would like to report on my experience using
both C and Smalltalk for experimental computer music work.

In order to do the experiments of interest, which had to do with
tools for the composer and musical accompaniment, it was necessary to
interface the computer with a music synthesizer and keyboard. In a
three month period in late 1986 and a three week period in late 1987
I implemented essentially the same underlying library of utilities,
the first time in Lightspeed C on a Mac+ and the second time in
Smalltalk on a Tektronix 4405. The experimental software I built on
top of these two frameworks was different, so I will restrict my
comments to the development of the framework itself.

	1. Development Time
	   Development time in Smalltalk was a quarter or less the
	   time for the same task in C. Some of the time
	   saved came from not having to manage include files and
	   the decomposition of source code into modules. Some of it
	   came from faster debugging in Smalltalk and from the higher
	   level utility objects available in Smalltalk (like collections).
	   Some came from not having maintain consistent declarations
	   in several places and from not having to search through
	   multiple files for the right places to make changes. Finally,
	   some time was saved by not having to worry much about
           comments and formatting. Notice that much of the speed of
           development in Smalltalk has to do with the environment
           rather than the language. However, freedom from storage
           management concerns is really a time saver in Smalltalk,
           both in designing and writing the code and in debugging.
           (Finding pointer problems in C can be a demoralizing
           nightmare; in Smalltalk, even when the program fails it
           is easier to find the problem.)

	2. Garbage Collection and Performance
	   I expected to have performance problems in Smalltalk and
	   I was planning to move time-critical code into user-defined
	   primitives after debugging the system and identifying
	   the performance bottlenecks. I was surprised to discover
	   that the system performed fine without this measure. It
	   could perform about 150 notes per second continuously.
	   I did have some problems handling the large amount of
	   real time data sent by some keyboards, but was able to
	   write a filter (still within Smalltalk) to handle this
	   problem. Garbage collection also turned out not to get
	   in the way despite the sensitive timing requirements. I
	   did put some thought into the run-time data structures to
	   minimize the storage throughput needs. However, these
	   optimizations were easily added after getting the
	   initial implementation working.

I will mostly let my experience speak for itself. However, the story isn't
complete if I fail to mention that, subjectively, I enjoy working with
Smalltalk more than with C. I find it less frustrating. I make fewer
silly mistakes ("oh, I typed '=' and meant '=='") in Smalltalk and I
can find the remaining mistakes much faster. I like letting the system
organize my code and data structures for me. And I find that NOT having
explicitely defined types save time, both because you don't have to type in
all those declarations and because I can change my mind without having
to fix all the existing declarations.

No doubt, however, that if I could perform 2000 notes/second I'd find
use for the extra cycles (drawing the score while the music plays, for
example). So I hope that either someone will do a "code extractor/optimizer"
for Smalltalk or else that C++ will one day have all the nice amenities
of the Smalltalk world (garbage collection, debugger, browser-like
editor, incremental compilation, automatic type inferencing, etc).

		-- John Maloney (jmaloney@june.cs.washington.edu)