This reveals the presence of control and non-printable characters in the
errors returned by the Parse functions. Also add unit tests for NumError.
R=golang-dev, r, rsc
CC=golang-dev
https://golang.org/cl/7393075
This CL also replaces similar loops in other stdlib
package tests with calls to AllocsPerRun.
Fixes#4461.
R=minux.ma, rsc
CC=golang-dev
https://golang.org/cl/7002055
All packages place testdata in a specific directory with the name
"testdata". The mime and strconv packages have been updated to use
the same convention.
mime: Move "mime/test.types" to "mime/testdata/test.types". Update test
code accordingly.
strconv: Move "strconv/testfp.txt" to "strconv/testdata/testfp.txt".
Update test code accordingly.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7098072
If ParseUint is like ParseInt it should have the same parameter
names, thus rename b to to base as in ParseInt's documentation.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6453152
The improvement is obtained by eliminating the zero
initialization of a large structure that is only
needed when the fast path fails.
Also add a missing roundtrip test for float32s.
benchmark old ns/op new ns/op delta
BenchmarkAppendFloatDecimal 301 180 -40.20%
BenchmarkAppendFloat 486 388 -20.16%
BenchmarkAppendFloatExp 492 383 -22.15%
BenchmarkAppendFloatNegExp 478 370 -22.59%
BenchmarkAppendFloatBig 650 541 -16.77%
BenchmarkAppendFloat32Integer 308 180 -41.56%
BenchmarkAppendFloat32ExactFraction 449 333 -25.84%
BenchmarkAppendFloat32Point 494 390 -21.05%
BenchmarkAppendFloat32Exp 488 387 -20.70%
BenchmarkAppendFloat32NegExp 488 378 -22.54%
R=r, rsc
CC=golang-dev, remy
https://golang.org/cl/6346081
Fixes#3495.
I adapted fmt.TestCountMallocs to fix the
existing tests. As the resulting tests did not
appear to belong to either itoa or ftoa I moved
them into their own file.
R=bradfitz, fullung
CC=golang-dev
https://golang.org/cl/5985072
We need a compact, reasonably efficient IsPrint. That adds about 2K of data,
plus a modest amount of code, but now strconv is a near-leaf package.
R=r, bradfitz, adg, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/5756050
My theory is that the call to f() allocates, which triggers
a garbage collection, which itself may do some allocation,
which is being counted. Running a garbage collection
before starting the test should avoid this problem.
Fixes#2894 (I hope).
R=golang-dev, bradfitz, nigeltao
CC=golang-dev
https://golang.org/cl/5685046
It is possible that Linux and Windows copy the FP control word
from the parent thread when creating a new thread. Empirically,
Darwin does not. Reset the FP control world in all cases.
Enable the floating-point strconv test.
Fixes#2917 (again).
R=golang-dev, r, iant
CC=golang-dev
https://golang.org/cl/5660047
Cannot reproduce the failure locally,
but add explicit test in case some other
machine can.
Fixes#2917 (for now).
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5651071
Unexports runtime.MemStats and rename MemStatsType to MemStats.
The new accessor requires passing a pointer to a user-allocated
MemStats structure.
Fixes#2572.
R=bradfitz, rsc, bradfitz, gustavo
CC=golang-dev, remy
https://golang.org/cl/5616072
Consequently, remove many package Makefiles,
and shorten the few that remain.
gomake becomes 'go tool make'.
Turn off test phases of run.bash that do not work,
flagged with $BROKEN. Future CLs will restore these,
but this seemed like a big enough CL already.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5601057
The implementation is similar to the one from the double-conversion
library used in the Chrome V8 engine.
old ns/op new ns/op speedup
BenchmarkAppendFloatDecimal 591 480 1.2x
BenchmarkAppendFloat 2956 486 6.1x
BenchmarkAppendFloatExp 10622 503 21.1x
BenchmarkAppendFloatNegExp 40343 483 83.5x
BenchmarkAppendFloatBig 2798 664 4.2x
See F. Loitsch, ``Printing Floating-Point Numbers Quickly and
Accurately with Integers'', Proceedings of the ACM, 2010.
R=rsc
CC=golang-dev, remy
https://golang.org/cl/5502079
is consistent with what the Go compiler returns when such sequences
appear in string literals.
Fixes#2658.
R=golang-dev, rsc, r, r, nigeltao
CC=golang-dev
https://golang.org/cl/5530051
A test intended for denormals erroneously returned true also for
infinities, leading to bad overflows and wrong error estimates.
R=rsc
CC=golang-dev, remy
https://golang.org/cl/5489091
The algorithm is the same as in the double-conversion library
which also implements Florian Loitsch's fast printing algorithm.
It uses extended floats with a 64-bit mantissa, but cannot give
an answer for all cases.
old ns/op new ns/op speedup
BenchmarkAtof64Decimal 332 322 1.0x
BenchmarkAtof64Float 385 373 1.0x
BenchmarkAtof64FloatExp 9777 419 23.3x
BenchmarkAtof64Big 3934 691 5.7x
BenchmarkAtof64RandomBits 34060 899 37.9x
BenchmarkAtof64RandomFloats 1329 680 2.0x
See F. Loitsch, ``Printing Floating-Point Numbers Quickly and
Accurately with Integers'', Proceedings of the ACM, 2010.
R=ality, rsc
CC=golang-dev, remy
https://golang.org/cl/5494068
The longest numbers we have to represent are the smallest denormals.
Their decimal mantissa is not longer than 5^1100. Taking into
account some extra size for in-place operations, 800 digits are
enough. This saves time used for zero intiialization of extra
bytes.
old ns/op new ns/op delta
strconv_test.BenchmarkAtof64Decimal 521 334 -35.9%
strconv_test.BenchmarkAtof64Float 572 391 -31.6%
strconv_test.BenchmarkAtof64FloatExp 10242 10036 -2.0%
strconv_test.BenchmarkAtof64Big 4229 4029 -4.7%
strconv_test.BenchmarkFormatFloatDecimal 1396 934 -33.1%
strconv_test.BenchmarkFormatFloat 4295 3341 -22.2%
strconv_test.BenchmarkFormatFloatExp 12035 11181 -7.1%
strconv_test.BenchmarkFormatFloatBig 4213 3229 -23.4%
strconv_test.BenchmarkAppendFloatDecimal 1031 600 -41.8%
strconv_test.BenchmarkAppendFloat 3971 3044 -23.3%
strconv_test.BenchmarkAppendFloatExp 11699 11003 -5.9%
strconv_test.BenchmarkAppendFloatBig 3836 2915 -24.0%
R=golang-dev, bradfitz, rsc
CC=golang-dev, remy
https://golang.org/cl/5491064
(Note that the Int and Uint benchmarks use different test sets
and thus cannot be compared against each other. Int and Uint
conversions are approximately the same speed).
Before (best of 3 runs):
strconv_test.BenchmarkFormatInt 100000 15636 ns/op
strconv_test.BenchmarkAppendInt 100000 18930 ns/op
strconv_test.BenchmarkFormatUint 500000 4392 ns/op
strconv_test.BenchmarkAppendUint 500000 5152 ns/op
After (best of 3 runs):
strconv_test.BenchmarkFormatInt 200000 10070 ns/op (-36%)
strconv_test.BenchmarkAppendInt 200000 7097 ns/op (-63%)
strconv_test.BenchmarkFormatUint 1000000 2893 ns/op (-34%)
strconv_test.BenchmarkAppendUint 500000 2462 ns/op (-52%)
R=r, rsc, r
CC=golang-dev
https://golang.org/cl/5449093
