Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2016-02-08 21:21:18

On 2/7/2016 3:21 PM, Emil Dotchevski wrote:
> 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.
>

I'm not sure why the topic has moved into a discussion of the overhead 
and performance of exception handling. I think the performance 
characteristics of EH are pretty well understood (at least around these 
hallowed halls).

Users who want a result<T> abstraction however are not interested in a 
solution like EH which is heavily biased in performance towards the 
non-error control flow.

Errors reported through a result<T> abstraction are usually not 
exceptional and I would expect comparable performance between the error 
and non-error control flow.

Using result<T> doesn't preclude exception handling. I think they work 
very well together.

i.e. in the case of text entry you might return a result<std::string>
valid text would return directly
invalid text would return an error code
failure to allocate memory for the std::string would throw an exception