Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Benchmark #72

Closed
kardianos opened this issue Jul 19, 2016 · 2 comments

Comments

@kardianos
Copy link
Contributor

commented Jul 19, 2016

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

This comment has been minimized.

Copy link
Member

commented Jul 19, 2016

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 19, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.