The current bytes test suit didn't come with endian based test
which causing #34549 can passed the try-bot.
This test will failed when little endian architecture simply using
load and compare uint.
Update #34549
Change-Id: I0973c2cd505ce21c2bed1deeb7d526f1e872118d
Reviewed-on: https://go-review.googlesource.com/c/go/+/198358
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This clarifies meaning of "case folding" Unicode equality with more familiar "case insensitive" wording.
For case folding properties see ftp://ftp.unicode.org/Public/UNIDATA/CaseFolding.txt.
Fixes#33447
Change-Id: I6ee85ab398679bf2a0b7d18693985ff0979d6c5a
GitHub-Last-Rev: accc915933
GitHub-Pull-Request: golang/go#34434
Reviewed-on: https://go-review.googlesource.com/c/go/+/196717
Reviewed-by: Rob Pike <r@golang.org>
The distribution of hash outputs when varying the seed is
not good enough on 32-bit platforms.
This isn't a likely attack vector (the adversary controlling the seed),
so it isn't a huge deal. Would be nice to fix, though. For now, just
skip this test.
Fixes#33988
Change-Id: Icf51ab687fc215422a5492ae78e6f414b33e04cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/193078
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The newly added functions create a copy of their input with all bytes in
invalid UTF-8 byte sequences mapped to the UTF-8 byte sequence
given as replacement parameter.
Fixes#25805
Change-Id: Iaf65f65b40c0581c6bb000f1590408d6628321d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/142003
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The compiler has advanced enough that it is cheaper
to convert to strings than to go through the assembly
trampolines to call runtime.memequal.
Simplify Equal accordingly, and cull dead code from bytealg.
While we're here, simplify Equal's documentation.
Fixes#31587
Change-Id: Ie721d33f9a6cbd86b1d873398b20e7882c2c63e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/173323
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
splittests already contains most of the tests that cover explode. Add
the missing ones and skip the append test for empty results which would
otherwise lead to an "index out of range" panic.
Change-Id: I2cb922282d2676be9ef85f186513075ae17c0243
Reviewed-on: https://go-review.googlesource.com/c/go/+/170126
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When I was working on the fix for #31038 (make TrimSpace return nil on
all-space input) I noticed that there were no tests for TrimLeftFunc
and TrimRightFunc, including the funky nil behavior. So add some!
I've just reused the existing TrimFunc test cases for TrimLeftFunc and
TrimRightFunc, as well as adding new tests for the empty string and
all-trimmed cases (which test the nil-returning behavior of TrimFunc and
TrimLeftFunc).
Change-Id: Ib580d4364e9b3c91350305f9d9873080d7862904
Reviewed-on: https://go-review.googlesource.com/c/go/+/170061
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
This change adds a fast path for ASCII strings to both
strings.TrimSpace and bytes.TrimSpace. It doesn't slow down the
non-ASCII path much, if at all.
I added benchmarks for strings.TrimSpace as it didn't have any, and
I fleshed out the benchmarks for bytes.TrimSpace as it just had one
case (for ASCII). The benchmarks (and the code!) are now the same
between the two versions. Below are the benchmark results:
strings.TrimSpace:
name old time/op new time/op delta
TrimSpace/NoTrim-8 18.6ns ± 0% 3.8ns ± 0% -79.53% (p=0.000 n=5+4)
TrimSpace/ASCII-8 33.5ns ± 2% 6.0ns ± 3% -82.05% (p=0.008 n=5+5)
TrimSpace/SomeNonASCII-8 97.1ns ± 1% 88.6ns ± 1% -8.68% (p=0.008 n=5+5)
TrimSpace/JustNonASCII-8 144ns ± 0% 143ns ± 0% ~ (p=0.079 n=4+5)
bytes.TrimSpace:
name old time/op new time/op delta
TrimSpace/NoTrim-8 18.9ns ± 1% 4.1ns ± 1% -78.34% (p=0.008 n=5+5)
TrimSpace/ASCII-8 29.9ns ± 0% 6.3ns ± 1% -79.06% (p=0.008 n=5+5)
TrimSpace/SomeNonASCII-8 91.5ns ± 0% 82.3ns ± 0% -10.03% (p=0.008 n=5+5)
TrimSpace/JustNonASCII-8 150ns ± 0% 150ns ± 0% ~ (all equal)
Fixes#29122
Change-Id: Ica45cd86a219cadf60173ec9db260133cd1d7951
Reviewed-on: https://go-review.googlesource.com/c/go/+/152917
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
generating frame information in errors will cause this
function to no longer be inlined.
Updates #29934.
Change-Id: I1d7bc11707f1872d7315f627bfb9a12afa41e358
Reviewed-on: https://go-review.googlesource.com/c/161760
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Cleans things up quite a bit.
There's still a few more, like runtime.cmpstring, which might also
be worth fixing.
Change-Id: Ide18dd621efc129cc686db223f47fa0b044b5580
Reviewed-on: https://go-review.googlesource.com/c/148578
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Currently there are no tests that vary the alignment of Compare arguments.
Since Compare is written in assembly on most platforms (in internal/bytealg)
we should be testing different input alignments. This change modifies TestCompare
to vary the alignment of the second argument of Compare.
Updates #26129
Change-Id: I4c30a5adf96a41225df748675f4e9beea413b35c
Reviewed-on: https://go-review.googlesource.com/c/122536
Reviewed-by: Lotus Fenn <fenn.lotus@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Rationale: small buffer optimization does not work and it has
made things slower since 2014. Until we can make it work,
we should prefer simpler code that also turns out to be more
efficient.
With this change, it's possible to use
NewBuffer(make([]byte, 0, bootstrapSize)) to get the desired
stack-allocated initial buffer since escape analysis can
prove the created slice to be non-escaping.
New implementation key points:
- Zero value bytes.Buffer performs better than before
- You can have a truly stack-allocated buffer, and it's not even limited to 64 bytes
- The unsafe.Sizeof(bytes.Buffer{}) is reduced significantly
- Empty writes don't cause allocations
Buffer benchmarks from bytes package:
name old time/op new time/op delta
ReadString-8 9.20µs ± 1% 9.22µs ± 1% ~ (p=0.148 n=10+10)
WriteByte-8 28.1µs ± 0% 26.2µs ± 0% -6.78% (p=0.000 n=10+10)
WriteRune-8 64.9µs ± 0% 65.0µs ± 0% +0.16% (p=0.000 n=10+10)
BufferNotEmptyWriteRead-8 469µs ± 0% 461µs ± 0% -1.76% (p=0.000 n=9+10)
BufferFullSmallReads-8 108µs ± 0% 108µs ± 0% -0.21% (p=0.000 n=10+10)
name old speed new speed delta
ReadString-8 3.56GB/s ± 1% 3.55GB/s ± 1% ~ (p=0.165 n=10+10)
WriteByte-8 146MB/s ± 0% 156MB/s ± 0% +7.26% (p=0.000 n=9+10)
WriteRune-8 189MB/s ± 0% 189MB/s ± 0% -0.16% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
ReadString-8 32.8kB ± 0% 32.8kB ± 0% ~ (all equal)
WriteByte-8 0.00B 0.00B ~ (all equal)
WriteRune-8 0.00B 0.00B ~ (all equal)
BufferNotEmptyWriteRead-8 4.72kB ± 0% 4.67kB ± 0% -1.02% (p=0.000 n=10+10)
BufferFullSmallReads-8 3.44kB ± 0% 3.33kB ± 0% -3.26% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
ReadString-8 1.00 ± 0% 1.00 ± 0% ~ (all equal)
WriteByte-8 0.00 0.00 ~ (all equal)
WriteRune-8 0.00 0.00 ~ (all equal)
BufferNotEmptyWriteRead-8 3.00 ± 0% 3.00 ± 0% ~ (all equal)
BufferFullSmallReads-8 3.00 ± 0% 2.00 ± 0% -33.33% (p=0.000 n=10+10)
The most notable thing in go1 benchmarks is reduced allocs in HTTPClientServer (-1 alloc):
HTTPClientServer-8 64.0 ± 0% 63.0 ± 0% -1.56% (p=0.000 n=10+10)
For more explanations and benchmarks see the referenced issue.
Updates #7921
Change-Id: Ica0bf85e1b70fb4f5dc4f6a61045e2cf4ef72aa3
Reviewed-on: https://go-review.googlesource.com/133715
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: Ide50aba940727a7b32cd33dea5315050f1a34717
Reviewed-on: https://go-review.googlesource.com/132237
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
bytes.NewBuffer's documentation says it can be used to set the initial
size of the buffer. The current wording is:
> It can also be used to size the internal buffer for writing.
This may led users to believe that the buffer (its backing array) is
fixed in size and won't grow, which isn't true (subsequent Write calls
will expand the backing array as needed).
Change the doc to make it clearer that NewBuffer just sets the initial
size of the buffer.
Fixes#27242
Change-Id: I2a8cb5bee02ca2c1657ef59e2cf1434c7a9bd397
Reviewed-on: https://go-review.googlesource.com/132035
Reviewed-by: Dominik Honnef <dominik@honnef.co>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A number of explicit function literals found through the
unlambda linter are removed.
Fixes#26802
Change-Id: I0b122bdd95e9cb804c77efe20483fdf681c8154e
Reviewed-on: https://go-review.googlesource.com/127756
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
The existing implementation of bytes.Compare on s390x doesn't work properly for slices longer
than 256 elements. This change fixes that. Added tests for long strings and slices of bytes.
Fixes#26114
Change-Id: If6d8b68ee6dbcf99a24f867a1d3438b1f208954f
Reviewed-on: https://go-review.googlesource.com/121495
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes#25435
The added test fails without the re-slice and passes with it.
Change-Id: I5ebc2a737285eb116ecc5938d8bf49050652830f
GitHub-Last-Rev: 454ddad7df
GitHub-Pull-Request: golang/go#25436
Reviewed-on: https://go-review.googlesource.com/113495
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The existing implementation only considers the special ASCII
case when the lower character is an upper case letter. This
means that most ASCII comparisons use unicode.SimpleFold even
when it is not necessary.
benchmark old ns/op new ns/op delta
BenchmarkEqualFold-8 450 390 -13.33%
Change-Id: I735ca3c30fc0145c186d2a54f31fd39caab2c3fa
Reviewed-on: https://go-review.googlesource.com/110018
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Move the IndexByte function from the runtime to a new bytealg package.
The new package will eventually hold all the optimized assembly for
groveling through byte slices and strings. It seems a better home for
this code than randomly keeping it in runtime.
Once this is in, the next step is to move the other functions
(Compare, Equal, ...).
Update #19792
This change seems complicated enough that we might just declare
"not worth it" and abandon. Opinions welcome.
The core assembly is all unchanged, except minor modifications where
the code reads cpu feature bits.
The wrapper functions have been cleaned up as they are now actually
checked by vet.
Change-Id: I9fa75bee5d85db3a65b3fd3b7997e60367523796
Reviewed-on: https://go-review.googlesource.com/98016
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
As per the comments in golang.org/cl/78617. Also leaving a comment here,
to make sure noone else thinks to re-introduce the iota like I did.
Change-Id: I2a2275998b81896eaa0e9d5ee0197661ebe84acf
Reviewed-on: https://go-review.googlesource.com/78676
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a regression introduced in golang.org/cl/28817. That change got
rid of the iota, which meant that the type was no longer applied to all
the constant names.
Re-add the iota starting at -1, simplifying the code and adding the
types once more.
Change-Id: I38bd0e04f8d298196bccd33651e29f5011401a8d
Reviewed-on: https://go-review.googlesource.com/78617
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 65851 (bytes) and CL 65910 (strings) “improve[d] readability”
by removing the special case that bypassed the whole function body
when chars == "". In doing so, yes, the function was unindented a
level, which is nice, but the runtime of that case went from O(1) to O(n)
where n = len(s).
I don't know if anyone's code depends on the O(1) behavior in this case,
but quite possibly someone's does.
This CL adds the special case back, with a comment to prevent future
deletions, and without reindenting each function body in full.
Change-Id: I5aba33922b304dd1b8657e6d51d6c937a7f95c81
Reviewed-on: https://go-review.googlesource.com/78112
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This should help make clear that Len is not counting runes.
Also delete empty string, which doesn't add much.
Change-Id: I1602352df1897fef6e855e9db0bababb8ab788ca
Reviewed-on: https://go-review.googlesource.com/78110
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
erifan01
HowJMay
Keith Randall
Keith Randall
Meng Zhuo
Andrew Medvedev
Maxim Eryomenko
Martin Möhrmann
Josh Bleecher Snyder
Tobias Klauser
Ben Hoyt
Ketan Parmar
Leon Klingele
Marcel van Lohuizen
dupoxy
Tim Cooper
LotusFenn
Brad Fitzpatrick
Iskander Sharipov
Erin Masatsugu
Alberto Donizetti
Kazuhiro Sera
Johan Brandhorst
bill_ofarrell
Dave Russell
Eric Pauley
Keith Randall
Wei Xiao
Daniel Martí
Russ Cox