This repository has been archived by the owner on Dec 1, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 701
PROPOSAL: Use strings.Builder for stack trace formatting #149
Comments
Not til 1.9 is deprecated, which won't be til the end of the year i'd say. |
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. |
Sure. Please include a benchmark to show the improvement in allocations.
… On 13 Feb 2018, at 02:59, Chris Stockton ***@***.***> 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.
|
cstockton
added a commit
to cstockton/errors
that referenced
this issue
Feb 17, 2018
cstockton
added a commit
to cstockton/errors
that referenced
this issue
Feb 17, 2018
cstockton
added a commit
to cstockton/errors
that referenced
this issue
Feb 17, 2018
lysu
pushed a commit
to pingcap/errors
that referenced
this issue
Sep 11, 2018
gregwebs
added a commit
to pingcap/errors
that referenced
this issue
Sep 11, 2018
reduce allocations when printing stack traces (pkg#149)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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: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.
The text was updated successfully, but these errors were encountered: