× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.