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

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)

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.

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

Comment 5:

Labels changed: added go1.1maybe.

Comment 6:

Labels changed: removed go1.1maybe.

Comment 7:

Is there anything left to do here?

Comment 8:

As fixed as it is going to get.

Status changed to Fixed.