search

pkg / errors

Simple error handling primitives
https://godoc.org/github.com/pkg/errors
BSD 2-Clause "Simplified" License
8.2k stars 697 forks source link

PROPOSAL: Use strings.Builder for stack trace formatting #149

Open cstockton opened 6 years ago

cstockton commented 6 years ago

Hello, I'm not sure how this project would feel about a performance inspired change but figured I would at least present my findings since the gains are pretty significant. I was curious what was causing so many allocations when a specific code path failed, around 150 or so total and found the culprit to be in the stack trace printing. By adding a format function with a signature of func(b *strutil.Builder, s fmt.State, verb rune) I was able to lower it down to 7 by iterating the stack first for a good length estimate and calling Grow. The exact numbers:

BenchmarkStackObtain/er/lazy-24               500000          3035 ns/op         288 B/op          1 allocs/op
BenchmarkStackObtain/pkg/errors-24            500000          3412 ns/op         320 B/op          3 allocs/op
BenchmarkStackPrint/1_Times/er/lazy-24        100000         24778 ns/op        7244 B/op          7 allocs/op
BenchmarkStackPrint/1_Times/pkg/errors-24      30000         56817 ns/op        4057 B/op        130 allocs/op
BenchmarkStackPrint/6_Times/er/lazy-24         10000        129898 ns/op       42020 B/op         37 allocs/op
BenchmarkStackPrint/6_Times/pkg/errors-24       5000        323686 ns/op       22739 B/op        765 allocs/op

Of course printing 6 stack traces will never happen, it's just to illustrate how quickly it can add up. Here is an example implementation, this project probably wouldn't want the Itoa (much better would be adding a simple Itoa to strings.Builder)- I was just toying around at that point to see how many more allocs I could spare, but that specific piece only saves at most the stack frame count.

davecheney commented 6 years ago

Not til 1.9 is deprecated, which won't be til the end of the year i'd say.

cstockton commented 6 years ago

Would you accept a bytes.Buffer pull request that did the same thing? Would just allocate a backing ahead of time similar to string builder and string() the byte slice.

davecheney commented 6 years ago

Sure. Please include a benchmark to show the improvement in allocations.

On 13 Feb 2018, at 02:59, Chris Stockton notifications@github.com wrote:

Would you accept a bytes.Buffer pull request that did the same thing? Would just allocate a backing ahead of time similar to string builder and string() the byte slice.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.