Trivial performance questions
geoff at gerrietts.net
Sat Oct 18 03:33:29 CEST 2003
Quoting Peter Hansen (peter at engcorp.com):
> I won't disagree with most of that (we're rapidly reaching near total
> agreement here! :-) but I do think that assuming "the code will always
> be touched" is a very healthy attitude, in the same way you think that
> at least trivial attention to performance is a healthy attitude.
Yes, I think we're pretty close to in accord here.
> As an XP team, we tend to consider that critical evaluation to be
> the domain of the customer, so we basically don't worry about it
> until there is feedback that we're doing the wrong thing. This,
> in cooperation with the customer, makes the best use of the our
> resources (for which the customer is paying, in effect). But,
> yeah, that's just the XP view of things.
And I'm working from the perspective of an internal customer. But I
also think that with an external customer; special care ought to be
paid to those pieces of software that you don't plan to live
exclusively inside the project.
> > A half-million micro-optimizations may not pay for themselves
> Phew! I seriously hope your group hasn't examined that many
> pieces of code with performance concerns in mind! We don't have
> even that many lines of code, let alone areas that could be
...well, no, we haven't. But we are approaching that many lines of
code. And a good deal of it is naive code, none of which we will be
able to reclaim the lost performance from without more profound reason
to refactor. Some of it we probably should, but it's a challenge to
effectively profile our code.
> There's some truth in that, but I can't shake the nagging feeling
> that simply by using Python, we've moved into a realm where the
> best way to optimize a serious problem area is to rewrite in C
> or Pyrex, or get a faster processor. (Like you, I can be
> persuaded, but this is what _my_ experience has taught me.)
Probably some truth in that, too.
> Actually, it's probably just that re-interpretation and discussion
> which proves so very useful, not the phrase itself. Like a Zen
> koan or something, it's too short (or ambiguous) to have direct,
> hard meaning, but the meme it carries is a valuable one with which
> to be infected. ;-)
> The same probably holds true about ambiguous biblical passages,
> I hate to admit.
There's an ambiguous koan-like meme that I like to break out now and
again -- I think it's due to Robert Anton Wilson but the years have
not been kind to my respect for authority:
Any proposition is true in some way, false in some way, and in some
way not pertinent to the matter at hand at all.
Spend enough time with the meme and it justifies both sides of the
> I'd vote for the latter. My group has been heavily junior in
> flavour. Perhaps another cause of the difference is our greater (?)
> emphasis on XP and test-driven development? I doubt anyone could
> say, but for sure your code is more heavily used. I don't even need
> to know what it does to say that. :-)
I'll believe you. :) We've scaled up to the point where we're happy
but bursting at the seams.
> I would agree that new developers would benefit from that kind of
> experience. One of the few reasons why a (good) university or
> college education can be of value to a programmer. So can critical
> reading of some decent books or web pages on the topic.
Yes. It's something of a rite of passage, in some ways. And maybe the
right way to respond to optimization questions is "focus on
algorithms, and learn which built-in constructs use lousy ones". I'm
not sure, but I find "thinking about optimization before your
processors melt is premature" to be more than a little disingenuous.
> I think Kent is merely on a par with the Pope, but is not Himself
> divine. ;-) Knuth is another story, perhaps. :-)
Great minds, but human -- all too human. ;)
Geoff Gerrietts <geoff at gerrietts net> http://www.gerrietts.net/
"Now, now my good man, this is no time for making enemies."
--Voltaire, on his deathbed, when asked to renounce Satan
More information about the Python-list