4 ms·
> errors.Is() is expensive. If you use it, check the error is non-nil first to avoid a pretty big performance penalty on the happy path. Am I missing something
by richbell 2y ago
> errors.Is() is expensive. If you use it, check the error is non-nil first to avoid a pretty big performance penalty on the happy path.
Am I missing something, or could this be partially mitigated by adding a check for `err == nil && target != nil` and vice versa, rather than `err == target`?
https://github.com/golang/go/blob/9b43bfbc51c469ec13fca24960834a75b2bf66eb/src/errors/wrap.go#L44 https://github.com/golang/go/blob/9b43bfbc51c469ec13fca24960...
- metadat 2y agoI wonder why the compiler can't be smart enough to optimize such a case.
- flexagoon 2y agoIt already does
- Tomis02 2y agoWe probably don't need programmers either, the compiler should be smart enough to know what the stakeholders mean.
- richbell 2y agoThe answer is apparently that the code I linked isn't released yet. The latest available release only checks if target is nil.
- ReleaseCandidat 2y agoWhat he is missing is that if the max. 3 pointer comparisons in (together with the function call of `Is`) if err == nil || target == nil { return err == target } are a "pretty big performance penalty", there isn't much work going on. I mean, of course, these 2 or 3 comparisons + the function call of `Is` are at least double that of err != nil even if `Is` would have been inlined by the compiler.
- richbell 2y agoActually, the `err == nil` check doesn't exist in the latest release. It was added recently, which would explain the significant performance cost. If err is nil, it doesn't return early. https://github.com/golang/go/blame/adbfb672ba485630d75f8b5598228a63f4af08a4/src/errors/wrap.go#L44 https://github.com/golang/go/blame/adbfb672ba485630d75f8b559...
- tommiegannert 2y agoNice find. This commit: https://github.com/golang/go/commit/af43932c20d5b59cdffca45406754dbccbb46dfa https://github.com/golang/go/commit/af43932c20d5b59cdffca454... from April 4.