Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-12-15 02:46:58

On 15 Dec 2016 at 15:01, Gavin Lambert wrote:

> > 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.

For a capture depth of seven frames, it costs about 30 microseconds 
on Microsoft Windows. Stack backtracing is inherently cache 
unfriendly. That is a lot more than throwing an exception.

The people on SG14 have tried quite hard to demonstrate that throwing 
exceptions is slower than alternatives, but it has proven 
surprisingly hard to conclusively prove it in real world code. I am 
sure the compiler vendors would say "I told you so ..."

> 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. 

Multiple orders of magnitude difference yes.

>   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.

Could you take a closer look at the actual implementation code 
please?

> Also, I'm not sure about other compilers, but with MSVC thrown 
> exceptions always carry a stack trace with them anyway; it's possible to 
> extract the stack trace from any exception with some platform-dependent 
> code (without any decoration on the throw -- and depending on build 
> options, it can even work for null references and other CPU exceptions, 
> although some misguided people dislike that).

I was not aware that this is the case except when /EHa is used. 
Indeed, I had thought one of the big optimisations of /EHs was 
precisely the fact that backtraces are *not* captured, thus making 
C++ exception throws vastly faster than Win32 structured exception 
throws and the point of using /EHs.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/