Java vs Go，性能，内存占用

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1801 天前的主题，其中的信息可能已经有所发展或是发生改变。

http://macias.info/entry/201912201300_graal_aot.md

这个场景下，小量数据 go>aot>jit，数据量越大，三者差别越小

9 条回复 • 2019-12-25 19:51:58 +08:00

Cbdy

2019-12-25 09:03:54 +08:00 via Android

Graal 现在有人用来跑生产了吗😂

BBCCBB

2019-12-25 09:04:56 +08:00

@Cbdy twitter 貌似就在跑.

MakHoCheung

2019-12-25 09:20:40 +08:00

最可惜的是编译时间和反射 API 的限制，不过 flutter 那块的 dart 的编译也对反射有限制。希望 Grallvm 越做越好

cnbattle

2019-12-25 10:07:04 +08:00

看了一下 ,画的图有毒... 中小数量差距相当大

liuxey

2019-12-25 10:27:28 +08:00

@cnbattle #4 因为 JIT 起步很慢，Go 直接最大马力跑，我觉得这种文章看看就好

abcbuzhiming

2019-12-25 10:34:01 +08:00

这个问题之前我问过
https://www.v2ex.com/t/587073
大家的看法是 Go 这种没有虚拟机的语言，天生在内存占用上就比 Java 有优势，但是 Java 的内存占用换来的是高吞吐。Go 的目的则是高响应，而吞吐就不如。

但是小型程序 Go 这种先天内存占的小的语言，确实很吃香的，尤其是现在云场景大家都希望用尽量少的资源跑尽量多的容器

Raymon111111

2019-12-25 10:37:24 +08:00

jit 这么差我怀疑作者的测试方法或者是所使用 jvm 本身的优化是不是有问题

qieqie

2019-12-25 10:38:56 +08:00 via iPhone

就跑一个快排似乎没什么说服力吧，
上个版本的 GraalVM EE 的 aot 我测出来只有 JVM 的三分之一，x86 上跑的 SciMark2.0 (科学计算的 benchmark)，
然后看官方建议加上了 Profile guided optimization，结果分数也没提升。

hzgit

2019-12-25 19:51:58 +08:00

本质上就是解释执行和编译执行的区别