1
lihongjie0209 2019-10-05 14:05:44 +08:00
你看一下 stream 的内部实现就知道了, 当然耗时啊。
|
2
Aresxue 2019-10-05 14:12:43 +08:00
刷题的时候语法糖和黑魔法就不要用了,不要求代码的优雅型,不然性能说不定会有损耗
|
3
wwqgtxx 2019-10-05 14:45:57 +08:00 via iPhone
刷题为了速度都是提前开好大数组然后从来不做类型检查的,真实程序谁这么搞怕是会被打死
|
4
Mirage09 2019-10-05 15:17:36 +08:00 via iPhone
lambda 的耗时也很大,但是每次写 comparator 都会被 IntelliJ IDEA 提示改成 lambda...
|
5
pwrliang 2019-10-05 16:20:30 +08:00
是的,昨天刷 Leetcode 遇到了,使用 IntStream 求 min 发现 46ms,换成 for 之后 5ms。lambda 封装了好多层,在工程上用用没问题,刷题的话还是用 for 吧,否则容易 TLE。
|
6
SoloCompany 2019-10-05 17:06:15 +08:00 via iPad
lambda 和 stream 怎么能等同?哪来的证据支持你说 lambda 耗时?
|
7
Jrue0011 2019-10-05 23:02:27 +08:00
是因为多了几层函数调用吧
|
8
Raymon111111 2019-10-05 23:14:58 +08:00
没有经过 jit 优化的代码讨论性能意义不太大
|
9
chocotan 2019-10-06 11:19:35 +08:00
再怎么语法糖你这从 1ms 到 40ms 也太夸张了,严重怀疑是代码写的有问题
|
13
Sasasu 2019-10-07 21:29:05 +08:00
异步流式 builder api 除了写法发生变化,有时候增加或者减轻了心智负担外还有个优点。
这些 api 都增强了语义,编译器能更好的理解你想干嘛,优化力度能开的很大。 比如 steaming api,业务要先 zap 再算加法,再 zap 再算除法。传统 api 要遍历好几遍,streaming 遍历一遍就算出来,对 cpu 缓存友好几倍。 反观 go 语言,在可预见的未来会比 java 还慢 |