strconv: not as fast as C

[gopherbot]

by qinhui99:

I found a very bad performance for strconv of Go.  I did some tests between Go and JAVA
for string function. You can see the test results, Go has a very bad performance
comparing  JAVA.  The strconv function is very bad performance and needed to do some
refactoring. Since the   strconv function is very important basic stone of Go , so I
need your help. Thanks

1. float32 to string
Go version: (GO 1.0.1, winxp)
go test ftoa_test.go -bench="."
BenchmarkFloat32ToStr     100000             12812 ns/op
ok      command-line-arguments  1.938s 
 
Java version: (JDK1.7 ,winxp , use the "-server" jvm parameter) 
Loop 10000000 times
Time costs 2.45952435 (s).
performance:2459 ns/op

2.  int32 to string
Go version: (GO 1.0.1, winxp)
go test  itoa_test.go -bench="."
BenchmarkFormatIntByQH    500000              2843 ns/op
ok      command-line-arguments  1.797s

Java version: (JDK1.7 ,winxp , use the "-server" jvm parameter) 
Loop 10000000 times
Time costs 0.695598031 (s).
performance:695 ns/op

3. float64 to string
Go version:
go test ftoa_test.go -bench="."
BenchmarkFloat32ToStr     200000             13046 ns/op
BenchmarkFloat64ToStr     100000             22656 ns/op
ok      command-line-arguments  5.594s

JAVA version:(JDK1.7 ,winxp , use the "-server" jvm parameter)
Loop 10000000 times
Time costs 5.079030794 (s).
performance:5079 ns/op

Attachments:

1. itoa_test.go (1375 bytes)
2. ftoa_test.go (1882 bytes)
3. AtoStringBenchmarkTest.java (613 bytes)
4. DoubleToStringBenchmarkTest.java (664 bytes)
5. FloatToStringBenchmarkTest.java (666 bytes)
6. BenchmarkTest.java (523 bytes)
7. B.java (74 bytes)

[remyoudompheng]

Comment 1:

For the moment, only the conversion string -> float64 and float64 -> shortest string is
optimized. The needs are:
- string->float32 (should be straightforward)
- float32 -> shortest decimal (should be straightforward)
- floatxx -> fixed precision

[rsc]

Comment 2:

I am not sure the performance of strconv is so terrible. These benchmarks are not
measuring apples and oranges. For one thing, the default Java float to string conversion
is more like Go's 'g', -1 than Go's 'e', 10.  
These are the numbers I get for the original test:
Original test:
BenchmarkFloat32ToStr     500000          5212 ns/op
BenchmarkFloat64ToStr     200000          7980 ns/op
And these are the numbers using 'g', -1:
Use 'g', -1:
BenchmarkFloat32ToStr     500000          6910 ns/op
BenchmarkFloat64ToStr     500000          5436 ns/op
Then, the test is still allocating lots of tiny strings. A real Go program, if this were
a bottleneck, would use AppendFloat with a buffer, so let's make the test measure that
(as the commented out benchmarks do):
Use AppendFloat:
BenchmarkFloat32ToStr     500000          4731 ns/op
BenchmarkFloat64ToStr     500000          3235 ns/op
That's 2.5x improved over the original.
The same applies to integer conversions:
Original:
BenchmarkFormatIntByQH   1000000          1301 ns/op
Use AppendInt:
BenchmarkFormatIntByQH   5000000           685 ns/op
I am using a 64-bit machine while you appear to be using a 32-bit machine. If I run the
32-bit compilers on the latest copy of the code, I get about a 2x slowdown. This could
probably be improved:
BenchmarkFloat32ToStr     200000          8444 ns/op
BenchmarkFloat64ToStr     200000          7323 ns/op
BenchmarkFormatIntByQH   1000000          1379 ns/op
Also, note that by measuring the implicit string conversion in your Java benchmarks you
are very likely to be measuring implementations written in C, not Java.

Labels changed: added priority-later, removed priority-triage.

Status changed to LongTerm.

Attachments:

1. x_test.go (824 bytes)

[gopherbot]

Comment 3 by qinhui99:

Thanks for your reply. It is my fault, I had thought that Go is faster than JAVA. Hence 
I tried to design the ETL tools with Go. Then I found sometimes the Go programs ran not
so fast as JAVA programs. That made me very disappointed and tried to find why. I really
tried to use the appendInt or appendFloat, but when one row contains too many int or
float, the data process still slowly(comparing to JAVA). 
If there are no good solutions for this issue, you can pass this issue.

[rsc]

Comment 4:

I'll leave the issue open for now. The 32-bit tools in particular do
lag a bit, because compilation is more challenging with next to zero
usable registers.
Russ

[rsc]

Comment 5:

Labels changed: added go1.1maybe.

[robpike]

Comment 6:

Labels changed: removed go1.1maybe.

[remyoudompheng]

Comment 7:

Is there anything left to do here?

[rsc]

Comment 8:

As fixed as it is going to get.

Status changed to Fixed.