bytes, strings: optimize Trim for single byte cutsets

Using the latest version of all modules known by the module proxy,
we determine that for all Trim usages (and related functionality):
* 76.6% have cutsets of len=1, and
* 13.4% have cutsets of len=2.

Given that a vast majority of usages only have a cutset of len=1,
we should more heavily optimize for that situation.
Previously, there was some optimization for cutsets of len=1,
but it's within the internal makeCutsetFunc function.
This is sub-optimal as it incurs an allocation in makeCutsetFunc
for the closure over that single byte.

This CL removes special-casing of one-byte cutsets from makeCutsetFunc
and instead distributes it directly in Trim, TrimRight, and TrimLeft.
Whether we should distribute the entire ASCII cutset logic into Trim
is a future CL that should be discussed and handled separately.
The evidence for multibyte cutsets is not as obviously compelling.

name                old time/op  new time/op  delta
bytes/TrimByte-4    84.1ns ± 2%   7.5ns ± 1%  -91.10%  (p=0.000 n=9+7)
strings/TrimByte-4  86.2ns ± 3%   8.3ns ± 1%  -90.33%  (p=0.000 n=9+10)

Fixes #46446

Change-Id: Ia0e31a8384c3ce111ae35465605bcec45df2ebec
Reviewed-on: https://go-review.googlesource.com/c/go/+/323318
Trust: Joe Tsai <joetsai@digital-static.net>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>

0 files changed, 0 insertions, 0 deletions