From: greg@qualcomm.com (Greg Noel)
Newsgroups: comp.sys.amiga.applications
Subject: Re: --- THIS IS MY WORD PROCESSOR ---
Summary: speed and space requirements
Date: 6 Apr 92 01:54:40 GMT
Organization: Qualcomm, Inc., San Diego, CA

After looking back over the messages about your word processor, it's clear
that there can't be any real complaints about the feature set.  Grumblings,
perhaps, that a particular feature isn't done just the way I want it, but no
real complaints.

And yet, with the Amiga a multi-programming machine, any application that
hopes to be accepted must effectively share the computer with lots of other
programs.  Why has there been no discussion of the two most important
attributes in that environment?

Right.  Speed and space.  There's been nothing said about the resources it can
be expected to use.

We know from all the programs written on the PDP-11 that no program needs to
ever be larger than 64K for both program and data, right?  The great success
of the PDP-11 UNIX system proves that it's a very reasonable restriction. 
Anything larger than that shows either a woeful lack of design skill or a
total disregard of good programming practices.

At the same time, it needs to be fast enough that background ray-tracing is
not significantly impacted.  In other words, response to almost any normal
keystroke shouldn't take more than, oh, a couple of milliseconds of CPU time,
even on a 7MHz 68000.  This should include the time to field the keystroke,
figure out what to do with it, and update the display.

OK, OK, before you guys go totally ballistic, let's see if I can get my tongue
out of my cheek....  (Thwock!)  There that's better!

Silliness aside, speed and space are important.  It takes conscious effort to
deprive your program of resources that seem to be available, but the fewer
resources your program takes, the better it will operate in conjunction with
other programs.  A program that won't run well on an unaccelerated 512K Amiga
500 won't be widely accepted, no matter how good it is.

And it's true that a little deprivation often makes a program better.  In all
seriousness, if you always program as if you were about to run out of memory,
you'll find that your programs are more robust because you tend not to make
assumptions that things will always work as expected.

There are ways to keep yourself from getting sloppy -- one of my favorites is
to pad all dynamic structures by 10,000, 100,000, or even 1,000,000 bytes. 
Then if you don't use memory economically or have a memory leak, you \will/
run out of memory, even on a large VM machine.  Not only that, your recovery
logic will be well-tested, since even a small test can run short.

Programming small works with code, too.  A little attention to writing the
shortest, most economical sequences often produces a better program, because
it forces you to look for the generalization that handles all the special
cases.  You end up with a smaller program that's both more robust and easier
to maintain.  And it's often faster, too -- splitting the control flow into
special cases takes time, more time than you would think, and often longer
than optimized special-case code can make up.

-- Greg Noel, Unix Guru         greg@qualcomm.com  or  greg@noel.cts.com
Newsgroups: comp.sys.amiga.applications