2 ms·
The happy path is still just nil comparison though: if err == nil || target == nil { return err == target } So the overhead is the function call and
by esprehn 2y ago
The happy path is still just nil comparison though:
if err == nil || target == nil {
return err == target
}
So the overhead is the function call and 2 comparisons. I wonder if the `isComparable := reflectlite.TypeOf(target).Comparable()` line was moved into a separate function if the compiler would inline Is() reducing the perf impact.
Possibly related: https://github.com/golang/go/issues/61502 https://github.com/golang/go/issues/61502
Looks like they're working on improving the inliner.
- deleted 2y ago[deleted]
- jamespwilliams 2y agoThat err == nil check was added very recently and isn’t included in the latest Go release, which the author used in this article.
- esprehn 2y agoAh ha! So the issue was always going through the error type reflection even for the success path. https://github.com/golang/go/commit/af43932c20d5b59cdffca45406754dbccbb46dfa https://github.com/golang/go/commit/af43932c20d5b59cdffca454... I'd be interesting to see the benchmark after that.