Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-03-01 10:52:37


Joaquín Mª López Muñoz <joaquin_at_[hidden]> writes:

> Peter Dimov ha escrito:
>
>> Pavel Vozenilek wrote:
>> >
>> > The reasons to use macros instead of RAII is convenience
>> > and performance.
>>
>> Can you elaborate please. I'm slowly coming to the conclusion that any catch
>> that can be replaced by RAII should be. Including the one in shared_count.
>> ;-)
>
> I think I can contribute here. Earlier versions of indexed_set did extensively
> use scopeguards in place of try-catch blocks. When doing the performance
> measures, I discovered that scopeguards were introducing a non-negligible
> penalty --for instance, a single-indexed indexed_set was 20% slower than
> its equivalent std container with scopeguards, and just 10% slower with
> try-catch blocks (rough figures.)
>

I believe that. It's hard for scopeguards to compete with try/catch
in cases like:

  try {
     ...
  }
  catch(...)
     // cleanup in this case only
     ...
     throw;
  }
  // no cleanup

  In cases like:

  try {
     ...
  }
  catch(...)
     // cleanup
     ...
     throw;
  }
  // the same cleanup again

getting RAII to be as efficient as try/catch generally depends on the
optimizer. If the resources can fit into registers in the try/catch,
the optimizer needs to be smart enough never to put them on the stack
in the RAII case. Speaking generally, that's pretty unlikely,
especially on systems that bind SEH and C++ exceptions together.

I think Scott Meyers once told me that Microsoft engineers had told
*him* that try/catch costs more than constructing an object with a
nontrivial destructor. I didn't see how it was possible, and your
measurements seem to confirm my suspicions.

> See http://tinyurl.com/33e4a for current performance results.

Can't see much of use there, FWIW; the graphs don't show. I had to
check the material out from the sandbox CVS.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk