On Sun, Feb 7, 2016 at 11:02 AM, Domagoj Saric
On 6.2.2016. 21:48, Emil Dotchevski wrote:
Another stated concern is that exception handling introduces overhead throughout the program even when exceptions are not being propagated, however such overhead (if any) is limited to function call and exit points. In performance-critical contexts function calls are too expensive with or without the added overhead of exception handling, and the solution is to inline the function. In that case all function call overhead disappears, including the exception handling overhead.
However * this reasoning is only valid (and even then not fully) in synthetic tests/non-real world analysis - i.e. 'my program is the only one on the system' - on a real system, this reasoning is merely the number one licence to produce bloatware as there everything is 'performance critical' - your 'non critical' (i.e. fatter and slower than necessary) code (in addition to contributing to OTA and flash storage costs, IO, fragmentation...) might be loaded and/or executed (or simply occupy the virtual address space) at the same time that another app is trying to "squeeze the most of a user's device" (i.e. running its 'critical' part)
There are upsides to "slower" code. Are you saying that *your* code can't be optimized any further? :) Or is it that you've chosen to draw the line arbitrarily at "exception handling is too slow"? Code size does matter on a system with, say, 32 megs of ram, like the Playstation 2. If, on a modern system, the size of your code is the reason why you're running out of memory or address space, exception handling overhead is the least of your worries. :)
* inlining is, in general, a primitve bruteforce solution that can only exacerbate the problem of bloatware (discussed this in more detail relatively recently with Andrey Semashev)
Indeed, inlining shouldn't be used throughout the code, to avoid bloat and for many other reasons. When you can afford the cost of a function call you should opt to pay it because this reduces physical coupling.
* even the very latest MSVC compiler cannot inline functions that contain certain types of EH (even something simple as having a by-value parameter that has a non-trivial destructor)...
So? Either you can afford the function call, or you must tweak the code until the call disappears. The hard fact in discussions about exception handling overhead is that either 1) you can afford it or 2) you can easily remove it selectively, by using inline. Emil