Re: [boost] expected/result/etc

On 2/7/2016 3:21 PM, Emil Dotchevski wrote:

On Sun, Feb 7, 2016 at 11:02 AM, Domagoj Saric 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 resultstd::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