On 28/04/2019 18:40, Ben Craig via SG14 wrote:
> Before reading, ask yourself "Can my opinions be changed by data?". If
> the answer is "no", then reading this paper probably isn't an effective
> use of your time.
>
> Attached is a a draft paper that measures the size cost of various error
> handling techniques (apologies for the half meg paper, the fancy graph
> javascript is kind of big). Exceptions, return codes, abort, and many
> other strategies are covered.
>
> If the attachment doesn't make it through for whatever reason, the html
> is also saved on
> github: https://github.com/ben-craig/error_bench/blob/master/error_size_benchmarking.html
>
> I plan on putting this in the pre-Cologne mailing.
>
> Let me know if I have misrepresented any error handling technique, or if
> my methodology is flawed in some way.

I would reiterate my surprise at how poorly Outcome +
experimental::error performs, and remind folk that an issue has been
logged for this to https://github.com/ned14/outcome/issues/186.

Taking a quick look at https://godbolt.org/z/CgWdWX, there are two major
sources of surprise:

1. The table of errc to string representations is constexpr, and ought
to be entirely elided in the output under C++ 14 or later. But it is
not, and I am quite sure that it used to be. So something has gone wrong
there.

2. The source code never converts error to text, so the text conversion
machinery should be optimised away, but is not being optimised away.
Again, I am quite sure that this used to be so. I suspect it was the
removal of a number of `final` modifiers.

I will investigate this at some point in the future. Currently sitting
in a WG14 C standards meeting!

Niall