Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-12-15 04:49:26

On 12/15/16 05:01, Gavin Lambert wrote:
> On 15/12/2016 12:44, Andrey Semashev wrote:
>> On 12/15/16 02:27, Peter Dimov wrote:
>>> This sounds like a pretty good idea, although I'm not sure if we can
>>> enable it by default as people have historically been very sensitive to
>>> changes to BOOST_THROW_EXCEPTION. But an opt-in macro should be fine and
>>> very useful as one would automatically get stack traces from every use
>>> of BOOST_THROW_EXCEPTION. Hello Java.
>>
>> I've not taken a look at the proposed Stacktrace library, but from what
>> I know obtaining a stacktrace is typically a rather expensive operation.
>> I expect it to be no less expensive than throwing the exception. That's
>> probably too much to pay for by default. Plus, it adds one more
>> dependency on another library via such a core component as
>> BOOST_THROW_EXCEPTION.
>
> Capturing the stack to later perform a trace is relatively cheap and
> fast (though perhaps memory wasteful, though you usually wouldn't care
> about that unless the exception was due to running out of memory).  It's
> interpreting that data into a human-readable trace that's the slow part.
>  And I've previously asked about this and been assured that this library
> does do this in two separate phases to reduce performance impact at the
> trace site.

If that's the case then it would be nice to have some benchmark results 
before we impose that cost on everyone using BOOST_THROW_EXCEPTION.

 From my understanding (please, correct me if I'm wrong), even if you 
don't interpret the stacktrace, just to obtain it one has to iterate 
through the stack frames up to the beginning of the stack or some limit 
(which is not currently specified in BOOST_THROW_EXCEPTION). This has a 
linear complexity on the call depth. Throwing the exception, OTOH, is 
linear on the number of stack frames that need to be unrolled, plus 
other overhead such as exception construction and automatic variable 
destruction. Arguably, the latter complexity is typically less than the 
former, or the same in the worst case.