|
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