Re: Avoiding disk arms with CLOB

No disagreement here - context is everything - Cornell's quote was in a book on coding with VB, with many more words around his 3 rules.

And even in 1995, looking for some arcane optimization trick meant unmaintainable code.

I think the point I'd make is, don't optimize for the sake of optimizing.

Later
Vern

On 9/19/2013 1:52 PM, Rory Hewitt wrote:

Vern & Scott,

Just to fan the fire...

This doesn't mean that you shouldn't *think* about performance up-front.
It's absolutely a good thing (IMHO) to analyze where bottlenecks are *likely
* to occur and to think about how to minimize their likelihood and even, in
some cases, to code for them.

Yes, I'm fighting Rob Pike on this one - most bottlenecks *don't* occur in
surprising places; they occur exactly where you think they probably will,
if you've done any decent analysis. For instance, in RPG programs, it's *
probably* going to be I/O-related or due to repeated memory (re)allocations
or 'communications' (especially if web- or socket-related) and not in the
code itself, unless you're doing crazy bad loops...

Too often, Knuth et al. are invoked and result in bad code being written,
on the theory of "Let's get it done and then worry about making it fast".
And then there's no time/money to fix any performance-related issues...
There is a *huge* difference between optimization and coding for
performance. Lots of people don't know this, and they take the quotes below
on blind faith.

Rory

On Thu, Sep 19, 2013 at 11:39 AM, Vernon Hamberg
<vhamberg@xxxxxxxxxxxxxxx>wrote:

Add to these Gary Cornell's 3 Rules of Optimization -

Don't!
Don't!
Don't!

HTH and TIA
Vern

On 9/19/2013 12:04 PM, Scott Klement wrote:

On 9/19/2013 8:21 AM, RPGLIST wrote:

I'm facing the need to process a very large amount of data, which is

more

than likely going to come in as a SOAP or XML stream but I need to

process

this quickly and without losing time with the disk arms if at all
possible.

With all of the networking going on here, all of the SOAP processing,
XML parsing, etc, you're worried about the speed of the hard drive? I
would not be.

You should start by writing your program in the most "correct", easy to
understand, easy to maintain manner. And then, look for performance
problems in actual usage. If you do have a problem, measure what's
taking the time,and determine from that how to optimize it.

More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason — including
blind stupidity." -- W.A. Wulf

"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil." -- Donald Knuth

"Bottlenecks occur in surprising places, so don't try to second guess
and put in a speed hack until you have proven that's where the
bottleneck is." -- Rob Pike

The First Rule of Program Optimization: Don't do it. The Second Rule of
Program Optimization (for experts only!): Don't do it yet." -- Michael
A. Jackson