Trivial performance questions

[Peter Hansen]

Paul Rubin wrote:
> 
> 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.  

Wait, wait, wait....  hang on a second.  We were talking in a Python
newsgroup about Python development and optimization, and my comments
above relate solely and exclusively to that context.  You are talking
about embedded development, certainly not with Python (though we use
it in that way, but we're nearly unique I think), and I agree totally 
with you and Geoff and anyone else who wants to put forward the position 
that worrying about performance in advance is an important step in, 
say, more static and less readable languages where testing is harder 
and refactoring next in line with suicide in terms of dangerous pastimes.

Python is a different story.  Python is *trivial* to refactor if one
has adequate tests (as one should, even if just because of the dynamic 
nature of Python) and, more to the point, it is definitely lower in
performance no matter what I or anyone else says for your "average"
programming task than, say, C.  

I say that since we're talking *exclusively* in the context of
Python (I was, in case that wasn't clear) one can *always* consider
a fallback to C or Pyrex and the option for faster hardware to be
possible steps, instead of merely doing profiling and local micro-
optimization ala some of Geoff's points (not to diminish the importance
of anything he said).

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

Oh, dang, you aren't even addressing my original points, as I thought
you were about to. :-)  You're talking about the typical O(xx) analysis
that is the basis of all serious performance analysis.  But then you're
saying that with really crappy code written by incompetent designers
and coders, without a decent process to control the spread of the
disease they create, one can't avoid the resulting predicament, with
my approaches or anyone else's.  No surprise there...

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

Maybe.  Maybe (and I think it's more likely) when you have electrical
engineers writing code, the only thing up-front design will do for you
is postpone the point at which they start coding, and then you're 
doomed anyway.

> And sure, there are all kinds of methodological platitudes about how
> to stop that situation from happening, but they are based on wishful
> thinking.  

The only platitude about that is that those kinds of people shouldn't
be allowed near the keyboard.

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

I'll consider myself fortunate to be in a real-world ("modern"?) 
situation where the software people contribute intimately to the
hardware designs and write all the code and, often, things work
much better as a result.  I've been in your shoes in the past and
know whereof you speak... I just don't think that's how it has to be
any more.

Anyway Paul, I can't really see where you disagree with much that I've
said, and in any case I mostly agree with what you said, other than
that I don't think it's inevitable that a bunch of hardware types have
to be the ones writing code (certainly not in my company anyway) so
I don't agree that my approach is inappropriate, except perhaps in 
some companies which, in my opinion, are doomed anyway. :-)  Heck,
at this point I figure anyone writing embedded code that isn't done
in a test-driven style(*) is probably doomed, so I'm pretty much an 
extremist in this respect!

-Peter

(*) We have a very nice in-house developed simulator, all in Python,
which we're turning into a most excellent test-driven development
framework for our embedded code.  Very promising early results, and
if this kind of thing catches on it could well revolutionize, for
at least some companies, embedded development and improve quality
immensely.  Nothing to do with performance, mind you, except that
other than a few experiments with Pyscho I haven't bothered worrying
about the performance of the simulator since it's (a) in Python, and
(b) already something like 1/60 the speed of the native CPU at 12MHz,
and this on a 600MHz Pentium III!!