Copies utf8 constants and EncodeRune implementation from unicode/utf8.
Adds a new decoderune implementation that is used by the compiler
in code generated for ranging over strings. It does not handle
ASCII runes since these are handled directly before calls to decoderune.
The DecodeRuneInString implementation from unicode/utf8 is not used
since it uses a lookup table that would increase the use of cpu caches.
Adds more tests that check decoding of valid and invalid utf8 sequences.
name old time/op new time/op delta
RuneIterate/range2/ASCII-4 7.45ns ± 2% 7.45ns ± 1% ~ (p=0.634 n=16+16)
RuneIterate/range2/Japanese-4 53.5ns ± 1% 49.2ns ± 2% -8.03% (p=0.000 n=20+20)
RuneIterate/range2/MixedLength-4 46.3ns ± 1% 41.0ns ± 2% -11.57% (p=0.000 n=20+20)
new:
"".decoderune t=1 size=423 args=0x28 locals=0x0
old:
"".charntorune t=1 size=666 args=0x28 locals=0x0
Change-Id: I1df1fdb385bb9ea5e5e71b8818ea2bf5ce62de52
Reviewed-on: https://go-review.googlesource.com/28490
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Check that it now properly handles \xC0 and \xC1.
Fixes#11733.
Change-Id: I66cfe0d43f9d123d4c4509a3fa18b9b6380dfc39
Reviewed-on: https://go-review.googlesource.com/17225
Reviewed-by: Russ Cox <rsc@golang.org>
Cover some functions that weren't benched before and add InString
variants if the underlying implementation is different.
Note: compare (Valid|RuneCount)InString* to their (Valid|RuneCount)*
counterparts. It shows, somewhat unexpectedly, that ranging over
a string is *much* slower than using calls to DecodeRune.
Results:
In order to avoid a discrepancy in measuring the performance
of core we could leave the names of the string-based measurements
unchanged and suffix the added alternatives with Bytes.
Compared to old:
BenchmarkRuneCountTenASCIIChars-8 44.3 12.4 -72.01%
BenchmarkRuneCountTenJapaneseChars-8 167 67.1 -59.82%
BenchmarkEncodeASCIIRune-8 3.37 3.44 +2.08%
BenchmarkEncodeJapaneseRune-8 7.19 7.24 +0.70%
BenchmarkDecodeASCIIRune-8 5.41 5.53 +2.22%
BenchmarkDecodeJapaneseRune-8 8.17 8.41 +2.94%
All benchmarks:
BenchmarkRuneCountTenASCIIChars-8 100000000 12.4 ns/op
BenchmarkRuneCountTenJapaneseChars-8 20000000 67.1 ns/op
BenchmarkRuneCountInStringTenASCIIChars-8 30000000 44.5 ns/op
BenchmarkRuneCountInStringTenJapaneseChars-8 10000000 165 ns/op
BenchmarkValidTenASCIIChars-8 100000000 12.5 ns/op
BenchmarkValidTenJapaneseChars-8 20000000 71.1 ns/op
BenchmarkValidStringTenASCIIChars-8 30000000 50.0 ns/op
BenchmarkValidStringTenJapaneseChars-8 10000000 161 ns/op
BenchmarkEncodeASCIIRune-8 500000000 3.44 ns/op
BenchmarkEncodeJapaneseRune-8 200000000 7.24 ns/op
BenchmarkDecodeASCIIRune-8 300000000 5.53 ns/op
BenchmarkDecodeJapaneseRune-8 200000000 8.41 ns/op
BenchmarkFullASCIIRune-8 500000000 3.91 ns/op
BenchmarkFullJapaneseRune-8 300000000 4.22 ns/op
Change-Id: I674d2ee4917b975a37717bbfa1082cc84dcd275e
Reviewed-on: https://go-review.googlesource.com/14431
Reviewed-by: Russ Cox <rsc@golang.org>
