Trivial performance questions

[Paul Rubin]

Peter Hansen <peter at engcorp.com> writes:
> > individually. But in the long term, when confronted with a total
> > system rewrite because the collected work can no longer perform
> > adequately, and standard optimization techniques have met with
> > diminishing returns, you're going to regret not having paid attention
> > the first time through, 
> 
> 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.)

That's not always either feasible or desirable.  For example, I once
worked on the user interface of an ATM switch.  It had to display a
connection list in sorted order, when they were stored in memory in
random order.  It did this by finding the smallest numbered
connection, then the next smallest, etc., an O(N**2) algorithm which
worked fine when the switch was originally designed and could handle
no more than 16 connections or something like that, but which ate a
lot of not-too-plentiful embedded cpu time when hardware enhancements
made hundreds of connections possible.  OK, you say, rip out that
algorithm and put in a better one.  The problem is that the "sorting"
code was intimately intermixed with the selection code which banged on
the hardware registers and dealt with all kinds of fault conditions,
and the display code, which was knee deep in formatting cruft, and had
grown like a jungle over years of maintenance as new releases of the
hardware kept sprouting new features.  In short it was typical
embedded code written by electrical (i.e. hardware) engineers who,
while they were not stupid people, just didn't have much understanding
of software technology or methodology.  We are not talking about some
three-line loop like

   concat = ''
   for s in stringlist:
     concat += s

that can be rewritten into a ''.join call.  This UI module was 5000 or
so lines of extremely crufty code and there was no way to fix it
without a total rewrite.  And a total rewrite couldn't ever be
scheduled, because there were always too many fires to put out in the
product.  The module therefore got worse and worse.  So that's a
real-world example of where a little bit more up-front design caution
would have saved an incredible amount of headache for years to come.

And sure, there are all kinds of methodological platitudes about how
to stop that situation from happening, but they are based on wishful
thinking.  They just do not always fit the real-world constraints that
real projects find imposed on them (e.g. that a complicated hardware
product is staffed mostly by hardware engineers, who bang out "grunt"
code without too much sense of how to organize large programs).  All
you can do is recognize that you have a little bit of programming
sophistication available, and try to maximize your leverage in
applying it where it makes the most difference.  Regardless of what
one thinks of C++, reading Stroustrup's C++ book after being through
experiences like the above makes it clear Stroustrup had had similar
experiences.  It's visible in his book, how various design choices of
C++ were motivated by the tensions inherent in those experiences.