Re: Converting Case with a Varying Field

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.