Re:Size cost of C++ exception handling on embedded platforms
by cheez on Monday May 16, 2016 @08:11AM
(#11705767)
To add clarity to this explanation where I think it's needed: The llvm 'invoke' op is effectively a pseudo-op and does not necessarily indicate what a backend will do. It looks something like this (the exact details, I forget):
The backend translates this into:
Notice that there is no conditional. However, if in function-to-call, you have:
This will be translated into a table lookup that checks which exception handler is valid for the current block. This is the slow part and is generally no worse (theoretically) than frame-based exception handling.
[ Parent
| on HN ]
Re:Size cost of C++ exception handling on embedded platforms
by openasocket on Monday May 16, 2016 @09:33AM
(#11706126)
How slow is slow? I don't have a good sense of scale for this. Are we talking hundreds of nanoseconds, or microseconds, or what?
Re:Size cost of C++ exception handling on embedded platforms
by rwallace on Monday May 16, 2016 @04:28PM
(#11709347)
In my experience (desktop and server, haven't tried it on a microcontroller) exceptions have for all practical purposes zero cost until you actually throw one, at which point the cost is ten thousand clock cycles. That figure has stayed surprisingly constant over two decades of hardware and compilers for three different languages. (And, obviously, it's a negligible cost for an exceptional situation, but you wouldn't want to use it for flow control in a crunch-heavy inner loop.)
Re:Size cost of C++ exception handling on embedded platforms
by willvarfar on Monday May 16, 2016 @05:01PM
(#11709588)
FWIW, the Symbian file server used an exception to get out of a crucial loop. It was a bit of laughable trivia, but a bunch of us set out to prove it was a bad idea... but on profiling it was provably noise. We moved from setjmp implementation to EABI zero-cost and it was still no issue.
Just a data-point and a good case of profiling beating intuition :)
Re:Size cost of C++ exception handling on embedded platforms
by cheez on Monday May 16, 2016 @09:49AM
(#11706212)
Theoretically, it's just as fast as frame-based exception handling which follows pointers up the stack. However, things that might impact the performance are things like code locality. For example, if the exceptional code hasn't been loaded into memory since it hasn't been needed, your program will need to stall while the code is loaded into memory.
So basically, assume it is fast as hell (zero-cost) until you hit an exceptional case (so don't use exceptions for flow control.) In fact, I no longer use exceptions at all. I just "make a note and move on". Having objects that don't cause catastrophic failures when they are "null" is a good first step.