Hi, My Name is Alex, and I am a Resource Waster

Oleg "XML MVP" Tkachenko nailed it. I'm a "resource waster" and proud of it.

I think the time has come where we can actually afford to trade off performance for maintainability. Although many Über-experts (Yourdon, Jackson, etc.) have been saying this for thirty years, I wasn't a true believer myself until a few years ago when I realized exactly how fast hundreds of millions of clock cycles per second is. It's absurdly fast.

But now-a-days we don't deal in 100,000,000's of clock cycles. Heck, you can't even give a few hundred megahertz computer to charity anymore. No, we're in the age of billions of cycles per second, twenty-four stage pipelines (actually, I think that was old news as of Pentium III), multi/dual-core-processors, and so on. A new consumer desktop computer from Dell can perform a good five, maybe six billion floating point operations per second.

Let's put that in perspective. If you were to print out 5,000,000,000 floating point problems (482.224 x 127.8038) at fifty per page, the stack of paper would be 6.2 miles (10km) tall*. That's the equivalent of twenty-six Empire State Buildings floor to tip. All computed in a single second. Is that fast enough for ya?

Yet some folks, like Mr. Tkachenko, still worry about speed. In response to my post about how exceptions really aren't bad to use, Oleg countered, explaining exactly what happens when you throw an exception:

  • Grab a stack trace by interpreting metadata emitted by the compiler to guide our stack unwind.
  • Run through a chain of handlers up the stack, calling each handler twice.
  • Compensate for mismatches between SEH, C++ and managed exceptions.
  • Allocate a managed Exception instance and run its constructor. Most likely, this involves looking up resources for the various error messages.
  • Probably take a trip through the OS kernel. Often take a hardware exception.
  • Notify any attached debuggers, profilers, vectored exception handlers and other interested parties

I have to admit, that does sound rather intimidating. I honestly had no idea that it did all that for just a lousy exception. But let's put it into perspective: billions of operations per second. Yes, this sounds like a lot of stuff for an exception. Yes, it is a lot. Yes, your computer can handle all that ten times over so freakin' fast you wouldn't know it happened.

Exceptions are the ideal way of dealing with exceptional circumstances. If your database stored procedure yells "Documents status may not be altered while an approval is pending," exceptions are the simplest way to wrap that up, jump across your tiers, and display the message directly to the client. Any other way of doing it would be needlessly more complicated.

So next time someone tells you "it's faster this way," put it in the "Gigahertz Perspective" and counter with "but, is it better?"

(*) 5,000,000,000 FLOPS
  / 50 lines per page
  * 0.1mm per page (standard for 20lb)
  / 1,000,000 mm per km
  = 10 km

 Empire State Building = 1250 feet


  • Interesting views. Surely at some point you must concern yourself with performance over architecture.

    Can you give some examples of that?

  • Throwing an exception should be something that slows the computer down. After all, it's a response to something that impedes the flow of your program. If you're throwing so many exceptions that you worry about the performance on Gigahertz processors then you're using exceptions counter to their design. They're no longer the exception, but the rule.

  • Alex,

    Can you try doing this at a... ummm... webserver that has 1000 people logged at it at the same time?

    Then unplug the database server and see what happens or do something that is otherwise disastrous?

    Just try :)


    I think they invented something for when servers go haywire. They're called "custom error pages" and they usually say something like "Hi, *web application name here* is currently undergoing technical difficulties. Please try logging in again later" or something shorter.

  • Well, may be I wasn't clear. For sure I'm with you on hating return code approach, that's really bad idea to never ever use exceptions but return codes. But another extreme - using exceptions for everything, even for normal flow - is equally wrong. As many noted, exceptions are for exceptional things.

  • Remember the "OLD" days when fuctions were written in C and returned error codes, where 0 meant no error? That's the way I still write code, albeit in C++, because I can't stand the idea that my program is wasting resources, time being the most important one. I must confess that I do put an exception trap at the top level, so as to not disturb the user with those awful windows exception messages.

Comments have been disabled for this content.