× 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.



At this point in time, for most situations, processing efficiency
rarely trumps programmer efficiency. More specifically,
maintainability; as maintenance is where most the cost of software
comes from.

http://en.wikipedia.org/wiki/Program_optimization#Quotes
"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. Yet we should not pass
up our opportunities in that critical 3%. A good programmer will not
be lulled into complacency by such reasoning, he will be wise to look
carefully at the critical code; but only after that code has been
identified"[5] — 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

Charles


On Tue, Aug 21, 2012 at 11:02 PM, Robert Houts <rshouts@xxxxxxxxx> wrote:
Sorry to disagree with you, as I do greatly respect your opinion, but processing efficiency ALWAYS trumps programmer efficiency. Any extra (read unnecessary) code is less efficient. The problem with most programmers (besides laziness) is that they usually don't look at the big picture, which is the code running in many jobs and possibly being called millions of times in a day. That "possibly negligible" amount of extra processing adds up in a hurry. Our production system does a lot of work (we wrap the job number every two to three days), so we need to remove inefficiency wherever we can.

It seems to me that however "very very fast" the bound calls are, calling the API directly is still faster. And that's the bottom line. Teaching programmers to value programmer efficiency over processing efficiency is a huge mistake.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.