Hacker News Reader

Comment by richbell | Hacker News Reader

> 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/9b43bfbc51c469ec13fca24960...

View on HN

What 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.

Actually, 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/adbfb672ba485630d75f8b559...

Nice find. This commit: https://github.com/golang/go/commit/af43932c20d5b59cdffca454... from April 4.

I wonder why the compiler can't be smart enough to optimize such a case.

It already does

We probably don't need programmers either, the compiler should be smart enough to know what the stakeholders mean.

The answer is apparently that the code I linked isn't released yet.

The latest available release only checks if target is nil.

Reply on news.ycombinator.com