Re: [stella] A warning to newbies -- every cycle becomes sacred!

Subject: Re: [stella] A warning to newbies -- every cycle becomes sacred!
From: "Mark Graybill" <saundby@xxxxxxxxxxxx>
Date: Tue, 6 May 2003 13:45:19 -0700
----- Original Message -----
From: Matthew Ozor <matt@xxxxxxxx>
To: <stella@xxxxxxxxxxx>
Sent: Tuesday, May 06, 2003 7:30 AM
Subject: Re: [stella] A warning to newbies -- every cycle becomes sacred!

> Visual Basic is for writing programs faster not writing fast programs.
> Worrying about cycles in 2 GHZ machines is unnecessary.

Usually, yes, but that's not entirely true. It's possible to squander any
amount of computing resources, since the resources are always finite but the
ability to squander them has no known limit.

As a case in point, there is the computing environment my wife supports.
They do builds of a software product on a high end multiprocessor system
with a number of other systems supporting it. It was taking about 12 hours
to do a build on these systems before they decided to do an upgrade. They
need to be able to do about 3 builds a day. The upgrade increased processor
speed and the number of processors to result in about a doubling of the
available CPU cycles, while also increasing the available RAM by about 50%.
They were shocked when the upgrade only resulted in the builds being reduced
to about 10 hours each.

After the upgrade debacle they finally allowed my wife to start implementing
some of a laundry list of fixes she had recommended they do before spending
money on more hardware. She implemented the fixes more or less in her spare
time around the other work she does on the systems, and also put together
another server out of old cast-off equipment to test her fixes. The test
hardware has less than 1/10th the CPU cycles, and less than 1/2 the RAM of
the production hardware. The build now takes about 6-8 hours on the test
hardware, and just over 3 hours on the production hardware.

The software they use to run builds is all written in Unix shell script,
awk, perl, and other RAD languages. One of their biggest problems was
profligate abuse of the Unix 'find' command (any use of which borders on
abuse, IMO.)

So I say go on counting cycles and thinking about optimizations, even in VB.
There are places in code where you can optimize the heck out of it and it
won't make a bit of difference. But there are also places in code where only
trimming a few parts of a percent off the time can pay off big time. Working
in a constrained enviroment like the 2600 is great training for learning
rules of optimization that are applicable at any level.

-Mark G.

Archives (includes files) at
Unsub & more at

Current Thread