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 {
     // cleanup in this case only
  // no cleanup

  In cases like:

  try {
     // cleanup
  // 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 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at