Hacker News Reader

Comment by jay-barronville | Hacker News Reader

Anyone who’s curious why `errors.Is()` is so slow (relatively speaking) should read the implementation [0]. It’s pretty obvious once you read the code—it relies on reflection followed by a tree-walking algorithm.

[0]: https://github.com/golang/go/blob/9b43bfbc51c469ec13fca24960...

View on HN

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

Looks like they're working on improving the inliner.

That err == nil check was added very recently and isn’t included in the latest Go release, which the author used in this article.

Ah ha! So the issue was always going through the error type reflection even for the success path.

https://github.com/golang/go/commit/af43932c20d5b59cdffca454...

I'd be interesting to see the benchmark after that.

Reply on news.ycombinator.com