bytes, strings: speed up TrimSpace 4-5x for common ASCII cases #29122
Labels
Milestone
Comments
|
Change https://golang.org/cl/152917 mentions this issue: |
|
Change https://golang.org/cl/169518 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Mar 27, 2019
Issue #29122 introduced a subtle regression due to the way that TrimFuncLeft is written: previously TrimSpace returned nil when given an input of all whitespace, but with the #29122 changes it returned an empty slice on all-space input. This change adds a special case to the new, optimized TrimSpace to go back to that behavior. While it is odd behavior and people shouldn't be relying on these functions returning a nil slice in practice, it's not worth the breakage of code that does. This tweak doesn't change the TrimSpace benchmarks significantly. Fixes #31038 Change-Id: Idb495d02b474054d2b2f593c2e318a7a6625688a Reviewed-on: https://go-review.googlesource.com/c/go/+/169518 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Per thread on golang-dev, I recently found that strings.TrimSpace is quite slow on a lot of common inputs, because it doesn't have a fast path for ASCII strings.
Adding a fast path for ASCII speeds it up 4-5x for ASCII cases, speeds it up somewhat for partially-ASCII cases, and doesn't (noticeably) slow it down for all-non-ASCII cases. So a pretty nice win for heavy users of TrimSpace like GoAWK. :-)
Thanks @josharian for helping me simplify and improve my initial version, getting it from 2-3x as fast to 4-5x as fast. The change is at: https://go-review.googlesource.com/c/go/+/152917
This is similar to #17856, where a similar ASCII fast path was introduced for strings.Fields and bytes.Fields.
For the record, I'm using go version
go1.11.2 darwin/amd64.The text was updated successfully, but these errors were encountered: