Yeah, that why i mentioned that benchmarking features is always contentious and it's easy to devolve into semantic argument... but here we go.
I guess it depends on what you mean by realistic and what is the benchmark trying to do. If by realistic, we mean "representative" in a sense that this code captures a good approximation o real work code, then i would argue that the original benchmark is completely wrong.
My version focus on being precise : measuring one thing (exception handling) in isolation as much as possible.
With that perspective :
1 - The cost of error handling also depends on the amount of information being reported. In the orginal benchmark, on one side the author is sending basically one bit of information and the other a full string. Pre-allocating the error was a way to normalize for that.
2 - I looked at the code, and most of performance delta between the two version came from the error code being vectorize, no_inline was a way to normalize for that as well.
Yeah, that why i mentioned that benchmarking features is always contentious and it's easy to devolve into semantic argument... but here we go.
I guess it depends on what you mean by realistic and what is the benchmark trying to do. If by realistic, we mean "representative" in a sense that this code captures a good approximation o real work code, then i would argue that the original benchmark is completely wrong.
My version focus on being precise : measuring one thing (exception handling) in isolation as much as possible.
With that perspective :
1 - The cost of error handling also depends on the amount of information being reported. In the orginal benchmark, on one side the author is sending basically one bit of information and the other a full string. Pre-allocating the error was a way to normalize for that.
2 - I looked at the code, and most of performance delta between the two version came from the error code being vectorize, no_inline was a way to normalize for that as well.