Go语言的一个大的性能瓶颈

最近在做一个Go和Java的读写文件的性能对比测试，结果意外发现了Go的一个性能瓶颈。Go语言字符串转换对象(strconv)性能超烂，比JAVA版本慢了几倍到几十倍。这应该也是国外的语言对比测试里面，Go的规则表达式表现糟糕的原因吧。我已经发邮件给Go开发组建议进行重构了。

测试1：循环1百万次，循环的每次操作为：把循环变量i转为字符串。例如，

for i:=1;i<=count;i++{

strconv.Itoa(i)

}

Go语言版本（strconv.Itoa(i)）

time costs(ns):328125000

time costs(ns)328 per operation

JAVA语言版本（””+i）

time costs(ns):111984107

time costs(ns):111 per operation

测试2：循环1百万次，循环里的每次操作为：把浮点变量1.0转为字符串。例如，

for i:=1;i<=count;i++{

strconv.FormatFloat(1.0,'e',10,32)

}

Go语言版本（strconv.FormatFloat(1.0,'e',10,32)）

time costs(ns):1093750000

time costs(ns)1093 per operation

JAVA语言版本（””+1.0）

time costs(ns):20155200

time costs(ns):20 per operation

time costs(ns):19801217

time costs(ns):19 per operation

－－－－－－－－－－－－－－－－－－－－－－－－

2012年6月11日

再次根据Go开发组的要求做了相关的对比测试，分别对一个int数组和float32数组进行循环转换字符串测试，排除了JDK缓存数据的因素。结果仍然一样。和JAVA相比，Go的strconv对象转换int和float32成字符串的性能超烂。

对比测试数据如下：

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