正如我们从2010 年的计算机语言基准游戏中看到的：
记住 Go 编译器会生成用于执行的本机代码，这怎么可能？ 不成熟的 Go 编译器？还是 Go 语言存在一些内在问题？
编辑： 大多数答案否认 Go 语言的内在缓慢，声称问题在于不成熟的编译器。 因此，我自己做了一些测试来计算斐波那契数：迭代算法在 Go (freebsd,6g) 中运行，same速度与 C 中一样（使用 O3 选项）。枯燥的递归在 Go 中的运行2 times速度比在 C 中慢（使用 -O3 选项；使用 -O0 - 相同）。但我还没有看到像基准游戏那样下降 10 倍。
same
2 times
6g 和 8g 编译器并不是特别优化，因此它们生成的代码不是特别快。
它们旨在自己快速运行并生成正常的代码（有一些优化）。gccgo使用 GCC 现有的优化通道，并可能提供与 C 的更有意义的比较，但 gccgo 还不是功能完整的。
gccgo
基准数据几乎完全与实施质量有关。除了实现花费运行时支持基准测试并不真正需要的语言功能之外，它们与语言本身并没有太大关系。在大多数编译语言中，一个足够聪明的编译器理论上可以剔除不需要的东西，但有时你会操纵演示，因为该语言的真正用户很少会编写不使用该功能的程序. 在不完全删除它们的情况下将事物移开（例如，在 JIT 编译的 Java 中预测虚拟调用目的地）开始变得棘手。
FWIW，我自己很琐碎与考验时，我正在看它（整数加法的循环，基本）围棋，gccgo产生对之间的范围内的快速结束码gcc -O0和gcc -O2等效C.围棋是不是天生就慢，但是编译器还没有做所有的事情。对于 10 分钟前的语言来说，这不足为奇。
gcc -O0
gcc -O2
