Cargo-Culted Optimisations
In Understanding User and Kernel Mode Jeff Atwood says that code that uses exceptions is slow because “exceptions imply kernel mode transitions”. From the ongoing debate in the comments it seems that this may be true for some languages running under .NET that use Window’s Structured Exception Handling but it’s misleading to state that it’s true in the general case.
There are all sorts of reason why exceptions might be slow - they’re just more code the CPU has to execute after all. I worry though about general claims that any idiom is slow. Search a selection of programming blogs for “X is slow” and I guarantee that in the comments someone will say “I never knew that. I’m going to avoid X in future”. I imagine that after a couple of years of cargo-culting these folks are working with a miniscule subset of their chosen language, circumscribed by all those “slow” things that they’re religiously avoiding.
Measure instead of guessing. Look for algorithmic complexity: if you can go from O(N^2) or worse to O(N log N), O(N) or O(1) you might gain far more than a few percent. But then again you might not - so measure.
This entry was posted on Friday, January 4th, 2008 at 12:44 pm and is filed under Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
4 Responses to “Cargo-Culted Optimisations”
-
Nick Says:
January 7th, 2008 at 9:33 amIt’s amazing how many design decisions are made without people measuring stuff. That’s why I was tasked to wite 29,000 lines of C last summer that *made no difference at all*. Still, I enjoyed the job purely for it’s interest value.
-
piers Says:
February 22nd, 2008 at 1:59 pmif you’re developing an app to be multi-platform you have to take into account the lowest common denominator. if UM/KM transitions are known to be costly on one platform it makes sense to minimise those from the outset - especially if there’s a large installed base. that isn’t cargo culting - that’s recognising that something’s a bit crap and accepting that there are potential consequences on other platforms.
i code in VHDL for hardware logic synthesis. there are many features of the language that would be great to use, but i have to use a restricted subset as experience with various customers’ various tools all at various patch levels has taught me to keep things simple. this can lead to inelegance in coding style, but it’s safe and reduces support costs. occasionally, someone tries to show how clever they are in their coding and we don’t find out until quite a way into the customer’s tool flow. we replace could that admittedly *should* work with clunky stuff and hey presto we can close the ticket.
the line between adherence to coding style guidelines and cargo culting can be thin in places.
-
piers Says:
February 22nd, 2008 at 2:02 pm> we replace could that admittedly *should* work
we replace code - not “could” - dog lobber.
-
Andy Says:
February 22nd, 2008 at 2:02 pmYeah, but my point was that exceptions don’t ordinarily involve any UM/KM transitions. It only (apparently) affects certain languages that run on CLR and use Microsoft’s structured exceptions. So it’s a mistake to perpetuate the idea that exceptions are slow based on one specific implementation.
CLR Structured Exceptions are slow. Exceptions in general are not.
Leave a Reply