Benchmark

[kardianos]

Hi Dave,

I like the API. I'm using this in govendor now.

When working on another project lower level lib, I thought I'd like to look at the performance impact. I'm not too concerned, but I wanted some numbers to put behind me before I used it. I didn't find a benchmark in this repo so I wrote one:

package errors

import (
    "fmt"
    "testing"

    "github.com/pkg/errors"
)

func noErrors(at, depth int) error {
    if at >= depth {
        return fmt.Errorf("no error")
    }
    return noErrors(at+1, depth)
}
func yesErrors(at, depth int) error {
    if at >= depth {
        return errors.Errorf("ye error")
    }
    return yesErrors(at+1, depth)
}

const stacks = 100

func BenchmarkNoErrors(b *testing.B) {
    var err error
    b.ReportAllocs()
    for i := 0; i < b.N; i++ {
        err = noErrors(0, stacks)
    }
    b.StopTimer()
    b.Logf("%v", err)
}

func BenchmarkErrors(b *testing.B) {
    var err error
    b.ReportAllocs()
    for i := 0; i < b.N; i++ {
        err = yesErrors(0, stacks)
    }
    b.StopTimer()
    b.Logf("%v", err)
}

It looks like the cost per op is roughly 1000-3000 ns. Which isn't a concern for me. But I'm glad to know it isn't more expensive.

[davecheney]

Thanks for benchmarking this, if you want to bundle this up into a PR I'd be glad to add it.

The thesis I'm operating under is the error path is the unexpected path and the costs of generating a stack trace is reasonable given the other costs associated with a cleanup and recovery in the error path.

[kardianos]

That's the same rational I'm using it with. That being said, it costs more than a cgo call by a considerable margin, so while normally it shouldn't be noticed, it shouldn't ever by in a hot loop that keeps returning errors... unless you want to slow that hot error producing loop down.

I'll send a PR in a bit.