Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-02-07 16:21:07

On Sun, Feb 7, 2016 at 11:02 AM, Domagoj Saric <dsaritz_at_[hidden]> wrote:

> 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