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
Closed

Benchmark #72

kardianos opened this issue Jul 19, 2016 · 2 comments

Comments

@kardianos
Copy link
Contributor

@kardianos kardianos 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
Copy link
Member

@davecheney davecheney 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.

Loading

@kardianos
Copy link
Contributor Author

@kardianos kardianos 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.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants