?

Log in

Previous Entry | Next Entry

The Cost of Exceptions

The other day at work I saw the following C++ code snippet:
CriticalSection.lock();
SomeFunc();
CriticalSection.unlock();

I noted that if SomeFunc() threw an exception the CriticalSection would remain locked. The writer of the code stated that they did not use exceptions. I asked why, and he stated that it was a performance issue.

I couldn't just let that go, so I wrote a test. In the test I have two functions that both add two parameters together and return the sum. The first function returns 0 if the sum is greater than 100. The second function throws an exception if the sum is greater than 100.

I call the first function 1 million times, measure the time it takes, and divide that time by 1 million to get the average time per call. On the Dell Precision 690 it took 0.010 microseconds per function call.

I call the second function 1 million times, with parameters which ensure it will not throw, and the average time per call is 0.011 microseconds per function call.

I call the second function 1 million times, with parameter which ensure it will throw every time, and the average time per call is 2.1 microseconds per function call.

There are a lot of things this test does not measure, such as code size, speed of nested functions etc, but overall it looks as if the overhead for exceptions is very small, until you actually throw an exception. And as we all know exceptions should be exceptional (therefore rare).

Using exceptions has its own problems, but citing poor performance as a reason not to use them is just laziness.

Comments

( 2 comments — Leave a comment )
chidorho
Oct. 24th, 2007 03:02 pm (UTC)
Shouldn't his answer have been simply: "I made sure SomeFunc() doesn't throw an exception because it's in a critical section."? Or was your point that he should have caught any exceptions inside the critical section?
grieve
Oct. 24th, 2007 04:37 pm (UTC)
Good Question
The function in question was actually specified in its declaration and definition to not throw.
SomeFunc() throw ()

So there should never actually be a problem, when I asked why they didn't use exceptions his statement was about performance. Which as I noted in the original entry is a lame excuse.

One thing I left out is the fact that even without exceptions I feel he should have wrapped the CriticalSection in a class which locks on construction and unlocks on destruction. I have used this with great success in many projects. This would change the code to something like:
{
  CriticalSectionGuard csg (myCriticalSection); // lock is acquired
  SomeFunc()
} // lock is released in almost all cases upon leaving the scope.

For the curious the lock would not be released if SomeFunc() were to call endthreadex() or its equivalent. Technically this applies to the exit() call as well, but if you called exit(), then everything goes away.

I learned this locking technique from either aroach or chikuru, but I honestly cannot remember who it was. Whoever it was, thanks for showing me that.
( 2 comments — Leave a comment )

Latest Month

July 2011
S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
31      

Page Summary

Powered by LiveJournal.com
Designed by yoksel