many small or 1 big?

Rob Cozens rcozens at
Mon Sep 9 11:06:20 EDT 2002

>This is OT from your request, but I think worth a philosophical comment.
>"The savings in HD space for the 1 BIG method is laughable these 
>days (I just bought an 80 GB HD for $150) and the savings in RAM is 
>rapidly becoming laughable."
>I believe that this kind of thinking can too easily lead one 
>unwittingly down the path of poor programming. It becomes easy to do 
>inefficient "quick-and-dirty" that works for a small program because 
>the inefficiencies are "covered" by all the available RAM and disk 

Hi All,

There was a time when RAM was expensive ($10,000 per megabyte for 
magnetic RAM in 1974) and typical computer configurations had 512K 
(yes, "K") RAM and 100 MB of disk storage or less.  In those days, 
programmers who could make the most efficient use of RAM & disk space 

In today's world, it is the programmer who writes source code that is 
easy to understand and modify that rules; because all those neat, 
esoteric code segments to minimize RAM & disk requirements tend to 
make the program source less straightforward, and today's clock 
speeds make runtime efficiency a moot issue in most user-interactive 
applications.  Gains in hardware efficiency are often lost many times 
over because of the added inefficiency in software maintenance.

Also, in my experience there is usually a trade-off between 
programming for hardware efficiency and programming for performance. 
For example, a database application could compress each record before 
filing it to minimize file size; but the trade-off is the overhead of 
compressing the record on writes & decompressing it on reads.  In 
this case, not compressing records to minimize disk storage 
requirements does not mean the application is "quick-and-dirty" and 
poorly programmed, but rather that the application is maximized for 
performance at the expense of larger file sizes.

Whether it is the legacy of the past or our professional appreciation 
of an elegant algorithm, we tend to spend more time trying to make 
code "efficient" than we do trying to make it understandable. 
IMF[oole's]O, there are few circumstances where a programmer needs to 
put more focus on efficient use of the hardware than on maximizing 
performance and maintainability.

Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)

More information about the Use-livecode mailing list