[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Nov 22 22:50:05 1992 
Subject:Re: Clarity VS Efficiency in POP11 
From:Steve Knight 
Volume-ID:921123.02 

In comp.lang.pop, tmr@cs.bham.ac.uk (Tim Read) writes:
> My conclusion is that (bearing in mind I am using an 86 MIP workstation), I
> will not worry about efficiency until I notice that my program is running
> slowly. 

It's good to hear from you Tim.  I can only half agree with this view,
though.  One can loosely divide efficiency improvements into 2 types;
local and global.  Local improvements are those that would be confined
to a single procedure (or a well defined collection).  Global improvements 
are those that require changes on a bigger scale.

What people tend to talk about when they discuss efficiency are small-
scale local improvements.  And these should not be tackled immediately,
since they are so easy to repair if required.  However, global 
efficiency issues should be designed in from as early as possible.

For example, if you have a very large data structure in your program
then you should always consider implementing it via a structured
file.  In one case I was involved in, not so long ago, shifting 
5Mb of data out of main store onto disc was the critical decision that 
allowed the program to run at all (and thereby determine the more
serious design problems.)  As it happened, the data consisted of a 
linear sequence of floating point values -- so this was exceedingly
easy.

> An example of what I mean is using a temporary closure within a
> loop, which looks nice and neat, but will cause extra garbage collections,
> as opposed to using an lblock (As Aaron pointed out).

Presumably "lblock" is a typo for "lconstant"?  I would agree that 
worrying about using partial application is foolish.  The current cost
of partial application are due to the design flaw of making closures
mutable.  Because they are mutable, the compiler cannot optimise
even the simplest of partial applications into constants.  I intend
to press for revision of this aspect of POP-11 in the Pop9x work.

> Until I notice that it takes longer for the program to run than it does for
> the data to be output, I'll lose no sleep over it....

I'll summarise my point here.  If you leave considerations of efficiency
very late then you may miss important design decisions that have to be
made early.  My recommendation is to put efficiency concerns at the top
of the agenda -- along with equally vital concerns such as designing
for debugging.  However, once the broad issues of efficiency are dealt
with it is then a mistake to dabble in the fine detail.

Steve