> that the actual performance cost for checking the error return is random, variable, and small. Good to know :)
That is certainly not the article's conclusion. The cost is deterministic, constant and non-negligible.
That is certainly not the article's conclusion. The cost is deterministic, constant and non-negligible.
I read that as "used to be non-negligable, is now negligable"
4%-10% depending on compiler and architecture is pretty variable, to my way of thinking. YMMV.
also kinda random, in that there's nothing I can do in the code to determine how much overhead it costs, or change that (apart from ignoring Go's convention on error handling completely, which I'm not going to do because it wasn't a convention for performance reasons in the first place).
The reduction in cost pertains to the try/catch (defer/recover) mechanism, not error returns.
The cost of error returns has not reduced since Go 1.10.
This is probably a matter of discretion. Considering the overall performance of Go applications compared to other languages, 4 to 10% is quite low. The measurement error might also be a few percent.