OJ 平台上同样代码逻辑如果使用 Java8 的 lambda 和 Stream 特性耗时会多很多

[1oNflow]

有的题目把 for 循环用 IntStream 改写一下，运行耗时直接从 1ms 变成 40ms，虽然代码更短更清晰了，但是不敢用，怕超时啊…

这是因为 OJ 一般只会跑一次，初始化很耗时吗？

[lihongjie0209]

你看一下 stream 的内部实现就知道了， 当然耗时啊。

[Aresxue]

刷题的时候语法糖和黑魔法就不要用了，不要求代码的优雅型，不然性能说不定会有损耗

[wwqgtxx]

刷题为了速度都是提前开好大数组然后从来不做类型检查的，真实程序谁这么搞怕是会被打死

[Mirage09]

lambda 的耗时也很大，但是每次写 comparator 都会被 IntelliJ IDEA 提示改成 lambda...

[pwrliang]

是的，昨天刷 Leetcode 遇到了，使用 IntStream 求 min 发现 46ms，换成 for 之后 5ms。lambda 封装了好多层，在工程上用用没问题，刷题的话还是用 for 吧，否则容易 TLE。

[SoloCompany]

lambda 和 stream 怎么能等同？哪来的证据支持你说 lambda 耗时？

[Jrue0011]

是因为多了几层函数调用吧

[Raymon111111]

没有经过 jit 优化的代码讨论性能意义不太大

[chocotan]

再怎么语法糖你这从 1ms 到 40ms 也太夸张了，严重怀疑是代码写的有问题

[nosilence]

@chocotan #9 实际上不夸张，你自己本地分别用 for 和 stream 试一下，就是差这么多

[zhady009]

@nosilence 怎么测试的? 我这边就快了 1ms..

[zhady009]

@nosilence 换了下 jdk 版本 jdk12 快 1ms jdk8 40ms

[Sasasu]

异步流式 builder api 除了写法发生变化，有时候增加或者减轻了心智负担外还有个优点。
这些 api 都增强了语义，编译器能更好的理解你想干嘛，优化力度能开的很大。

比如 steaming api，业务要先 zap 再算加法，再 zap 再算除法。传统 api 要遍历好几遍，streaming 遍历一遍就算出来，对 cpu 缓存友好几倍。

反观 go 语言，在可预见的未来会比 java 还慢