25 Oct
2011
25 Oct
'11
4:17 a.m.
On 2011-10-25 12:39, vintagecoder at aol.com wrote:
True enough. The problem, as I see it, is that too few programmers pay
attention to performance issue at programming time, and fixing a large
system after the fact, while sometimes painfully obviously possible,
becomes too large of an effort to undertake. Buying faster hardware will
solve the problem quicker, at equal or lesser cost.
It offends my programming heart to see code checked in that clearly
could benefit from some simple performance tuning and optimisation in
choosing storage formats. But "this is the tested version, changing it
will involve another complete test cycle" and there is always a deadline
to meet.
We migrated to new hardware at $WORK recently, and of course the first
few tests were promising: "wow, this thing really flies!" Well, just
wait until we've migrated out bloated database full of dead wood to it,
and all that great processing power will go towards making the damn
thing barely usable. In other words, looking on the bright side, "oh,
we'll soon bring this monster to its knees, too!" Heh. at least we have
room to grow, now. Lots of space for more Itanium boards in the machine,
provided HP manage to stay in business...
.tsooJ
More than performance, the issue was probably storage
in those days.
C'mon, I'm not /that/ old! ;-)
Programming
with performance in mind is a vanishing art and an unpopular
skill (in practice, that is; on paper, everybody pays lip service to it)
these days. The solution is almost invariably to throw new hardware at
the problem. Can't blame them, really. I mean, if I were in charge and a
programmer told me, "give me three years and I'll have it running twice
as fast on the current hardware," I'm pretty sure my reaction wouldn't be
to give the go-ahead on that one.
In practice choosing the right approach and coding sanely seems to produce
satisfactory results in critical pieces of code. I'm talking about the
commercial space because that's where you and I work and this may not apply
to embedded or other environments where the pipelining and
microoptimizations are better understood than where we work. Nobody should
think performance isn't a deadly serious thing in our environment, as you
said, the batch window is a factor and system availability is no joke
because of the fines, loss of revenue, and loss of customers that occur
when production is not up on time. Sometimes that is all the time. Companies
are willing to spend millions of dollars on one product to measure their
throughput or improve their transaction rate.