How To Counter The Myth Of Speed First

Recently, I've been engaged in several discussions with another programmer. He's a *very* good C++ programmer, probably better than I am, and whenever I bring up subjects like AlternateHardAndSoftLayers, DesignPatterns, or NecessaryAbstraction, he immediately counters with the reaction that these are all too slow, or involve too much overhead, or that the code savings doesn't matter in comparison to the raw speed.

Any significant abstraction, according to this argument, would be best to kept internally or on design documents meant for managers or lesser developers who don't know the language well enough yet.

What are good counter arguments to this kind of mentality? Everything in my experience tells me this mentality is wrong, but I'm having trouble making a cogent argument of it.

It depends. What are the requirements of the problem? Arguments that speed is all that ever matters; or that speed universally doesn't matter, are both bogus. You need to consider what the customer wants it to do; from then you can discern any necessary performance requirements. Note that "as fast as possible" is not a well-formed requirement; "needs to respond to user inputs within 100 milliseconds" (a common guideline from UserInterface research) is. In addition, the (functional) requirements need to be prioritized, traded off against schedule and cost limitations. Make sure the customers and stakeholders are involved in this process; not just the programmers (otherwise they may commit the ArchitectureAsRequirements fallacy and tell you that of course speed is the most important thing).

Often times the answer will come out that getting working code in customer's hands is more important than having the fastest UI on the block. This is especially true for lots of custom business software. And even when speed is identified as an important issue; often times the limiting factor will be I/O and not CPU bandwidth.

Once you know the requirements, then determine the architecture (including the language). It's an all-too-common AntiPattern to automatically reach for your favorite pet language without considering whether or not it is appropriate (or blindly believing that it is appropriate in all circumstances).

-- ScottJohnson

The best lessons come from examples where delaying optimization produced faster results. Those are hard to come by. Perhaps you can find some anecdotes by looking for info about CarHoare's maxim "premature optimization is the root of all evil".

Scott, exactly. Code only needs to run as fast as it needs to. It doesn't need to run faster. In an embedded domain, speed may be a primary requirement. In other domains, e.g., networked applications, GUI apps, database-centric systems, getting the application done sooner may be of more value.

But this still doesn't address the argument that abstractions are for lesser programmers. I'm not convinced that making something easier is akin to making something inferior. My experience with making domain specific languages tells me that sometimes by abstracting correctly you open up new doors in your problem domain and enable new solutions.

Does anyone know of any good arguments against this portion of his outlook? Since it is clearly a derogatory remark directed at me, I'm trying to come up with a particularly good rebuttal for it (naturally!). -- DaveFayram

Well, since he's from the C world: Ken Thompson is on record as saying that unoptimized "brute force" algorithms for Unix invariably turned out to be faster than later attempts by others at clever optimizations; in particular he (and actually, a lot of algorithm specialists) like the example of doing plain old linear search of an array or list until there's hard evidence proving you need to move to something fancier, like a tree or hash-map.
It tends to really surprise people when they really look into it, but they forget things like how fast the cpu goes when it's screaming through things prefetched to the data cache, etc, and that sort of analysis can be tricky and delicate anyway, so there's an argument for always starting very simply.
That does not make your point about abstractions, though, since that's already more concrete than e.g. CollectionClass?, but maybe one battle at a time?

Simply suggest to him that he ought to abandon programming languages (including AssemblyLanguage) altogether, and program in raw machine language. After all, these other things are all abstractions of the underlying hardware, designed so people who aren't geniuses like him (heh) can manage to get some work done despite their inferior intellect. :)

Use of C/C++, after all, is leaving precious implementation details to some compiler (as well as discarding precious optimization opportunities and increasing code bloat due to overly-generic libraries). It remains true that even the fastest optimizing compiler cannot outperform a skilled assembly language programmer when it comes to generating high-performance code.

(Of course, in most cases it doesn't matter; the industry abandoned use of assembly language for all but the most hardware-intimate and/or performance-intensive code years ago; and a similar migration is occurring away from C/C++ for much application code).

Another option is to point out that by choosing C in domains where it's inappropriate, he's bringing a knife to a gunfight. NeverBringaKnifeToaGunfight.

If all else fails, you can SetTheBozoBit on this guy. He appears to be caught up in his own (self-believed) superiority, and views his (apparent) skill in C as a significant mark of distinction. Since too-arrogant-for-their-own-good Lisp users have a page to document such churlish behavior :), I'm all for the creation of SmugCeeWeenies.

-- ScottJohnson

I'm tempted to start it too. There certainly are plenty of them. :) -- DaveFayram

I worked on a project once with a SmugCeeWeenie who declared we couldn't use Perl for this CGI application because it was "too slow." His "highly optimized" C code did DNS lookups by passing an "nslookup" command (with embedded file redirection) to system() and parsing the resulting output file. Certainly it was orders of magnitude better than Net::DNS! -- MarkSchumann

I've also been advised to suggest that C++ is such a wasteful and slow language compared to OcamlLanguage. Why isn't he going for high speed functional programming like a RealMan? should. For some reason, I think this argument is really funny. -- DaveFayram

I think that's really funny, too. What's holding you back??? Go for it! Show him the benchmarks! -- DougMerritt

See ProfilerTool (which gives an example where optimizing the "obvious" place wouldn't help), OptimizeLater, ProfileBeforeOptimizing, ...

If speed is all that matters, delay the product for a year, and newer CPUs will run it faster. MooresLaw helps all code equally. In most cases, "fast enough" is what the customer wants. A real example - my company has a subsystem that I work on that tracks device logins for a population of embedded devices talking to a server. About 5 years ago, someone in marketing decided that since our system can process X customer actions in a minute that it should also process X logins in a minute. So we refactored the loging tracking subsystem to process X + 10 logins per minute and published that benchmark. Since then, hardware improvements have taken this limit to 2X per minute on the loaded systems, and 3X on some smaller "typical" systems, all without alteration to the performance code. The current code is considerably more clear and simple than the previous code, and does not suffer the problems that a highly optimized subsystem might. We're being asked now to improve it some more, and we've got lots of room for improvement - multi-threading, caching data, etc. --PeteHardie

Also, the cynical side of me says that if you optimize for spped early, the customer will expect faster systems later on, and if you don't have any more inefficiencies to eliminate, you can't make the code faster! --PeteHardie

Don't Argue, Refactor

Instead of trying to debate ahead of time about architecture and design approaches, use the SimplestThingThatCouldPossiblyWork and then ReFactor to what looks nice. Every developer will have his own opinion as to what the initial solution should be, so whoever is doing the coding should make the call. The key is that the initial implementation must be followed by continuous refactoring. Eventually, all of the developers will meet in the middle; form a defacto consensus. Please note that for this to succeed, refactoring needs to be an accepted team practice; it cannot be secretly rewriting someone else's code.