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.
>> * 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk