How much do we care about high-load scenarios?

[Eric S. Raymond]

Eric S. Raymond <esr at thyrsus.com>:
> John D. Bell <JDB at systemsartisans.com>:
> > *If* I were the architect on this project (thankfully I'm not!) I
> > would get the code simplified and streamlined in single-thread mode
> > as far as possible, and then design and code a
> > POSIX-threading-conformant "improvement".
> 
> That is exactly the contingency plan I have unless Higher Authority (Mark
> and LF) tells me we need to do something else and do it now.

I should amplify that a little.

I will not willingly take the complexity hit of multithreading *anything*
until I see benchmark numbers demonstrating a bottleneck that can be
effectively addressed in no other way.  It's not good enough to just handwave
and say "high load, we gotta optimize" - without measurements optimization
is premature and you know what *that* means.

I can certainly do concurrent programming when I have to (there's a thread-pool
scheduler in the cvs-fast-export front end that I'm quite proud of - less than
30 lines of code to manage concurrent Bison parsers and the thing runs like
a bat out of hell) but I have an ingrained reluctance to do it that I've
been explaining off-list to Hal.

Human beings simply aren't very good at the kind of reasoning
concurrent programming requires. Even most programmers handle it
poorly. Thus, while adding threading might be a fun stunt for someone
at the mastery level of Hal or Gary or myself, it's a burden we should
think twice about laying on our successors.

All this comes under one of the least obvious but most important jobs
of a system architect - *defending simplicity*.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>