有的题目把 for 循环用 IntStream 改写一下，运行耗时直接从 1ms 变成 40ms，虽然代码更短更清晰了，但是不敢用，怕超时啊…
这是因为 OJ 一般只会跑一次，初始化很耗时吗？
这是因为 OJ 一般只会跑一次，初始化很耗时吗？
This topic created in 2425 days ago, the information mentioned may be changed or developed.
 |
1
lihongjie0209 Oct 5, 2019
你看一下 stream 的内部实现就知道了， 当然耗时啊。
|
 |
2
Aresxue Oct 5, 2019
刷题的时候语法糖和黑魔法就不要用了，不要求代码的优雅型，不然性能说不定会有损耗
|
 |
3
wwqgtxx Oct 5, 2019 via iPhone
刷题为了速度都是提前开好大数组然后从来不做类型检查的，真实程序谁这么搞怕是会被打死
|
 |
4
NVDA Oct 5, 2019 via iPhone
lambda 的耗时也很大，但是每次写 comparator 都会被 IntelliJ IDEA 提示改成 lambda...
|
 |
5
pwrliang Oct 5, 2019
是的，昨天刷 Leetcode 遇到了，使用 IntStream 求 min 发现 46ms，换成 for 之后 5ms。lambda 封装了好多层，在工程上用用没问题，刷题的话还是用 for 吧，否则容易 TLE。
|
 |
6
SoloCompany Oct 5, 2019 via iPad
lambda 和 stream 怎么能等同？哪来的证据支持你说 lambda 耗时？
|
 |
7
Jrue0011 Oct 5, 2019
是因为多了几层函数调用吧
|
 |
8
Raymon111111 Oct 5, 2019
没有经过 jit 优化的代码讨论性能意义不太大
|
 |
9
chocotan Oct 6, 2019
再怎么语法糖你这从 1ms 到 40ms 也太夸张了，严重怀疑是代码写的有问题
|
 |
13
Sasasu Oct 7, 2019
异步流式 builder api 除了写法发生变化，有时候增加或者减轻了心智负担外还有个优点。
这些 api 都增强了语义，编译器能更好的理解你想干嘛，优化力度能开的很大。 比如 steaming api，业务要先 zap 再算加法，再 zap 再算除法。传统 api 要遍历好几遍，streaming 遍历一遍就算出来，对 cpu 缓存友好几倍。 反观 go 语言，在可预见的未来会比 java 还慢 |
Select Language