感觉这次写的库能比 js 原生数组方法要快

[hupo0]

no-stream 似乎比 js 原生数组方法快

正在等待被锤的忐忑心理中。

[eason1874]

不太懂。是循环展开的意思吗？话说现在 JS 不是都要编译了吗，这个在编译时不会自动优化吗？

[hupo0]

@eason1874 应该不叫循环展开，是把多次循环合成一个。只见过 c++ 和 rust 有这类优化，而且对代码有不少限制，可能高级语言要考虑闭包什么的。

[cyberpoint]

比如程序员为了方便快捷就会写这种代码：const foo = bar.filter(...).map(...).reduce(...)
这样就会有 3 次遍历，但是其实这些...的过程是可以在一次遍历中完成的

[muzuiget]

明明就是写法问题，这种 [...xxx].map(xxx).filter(xxx).slice(xxx) 我为什么不直接用 for，也是一次循环。

[kkocdko]

是这样的，我记得 rust 的迭代器有这种优化

[hupo0]

@cyberpoint 表达到位

[Jirajine]

这个应该不是语言的优化吧，只要方法实现上不返回另一个数组，而是返回一个 lazy evaluation 的 iterator 就可以链式调用多次只遍历一次了。

[muzuiget]

谁白了这种链式求值，就是方便而已，不在乎这点性能损失，真遇到巨大数组，就应该专门写优化代码。

[supermao]

这种不需要猜，你自己做个 benchmark 不就出来了？

[supermao]

@supermao 原来已经做了。。。

[Rorysky]

@muzuiget 这不就是 java stream 的写法么

[hupo0]

@Jirajine iterator 转成另一个 iterator，一般是包多一层，该做的“结束检查”还是不会漏的，还是会有额外的性能损耗。实际用 benchmark 测也会发现比较慢。

[jones2000]

太高深了, 看不懂, 学了 2 年 js, 只会用 for(var i=0;i<data.length;++i) .......

[musi]

纠正一下，这不叫比“ js 原生数组方法要快”
js 可没让你本来遍历一次的事用三次遍历完成

[geelaw]

这个问题和数组遍历几遍没关系，主要区别在于内存分配。

Array.map 每次都要分配新的数组，可以想象 no-stream 的 map 只是变换迭代器，当然快。当然这不能怪 Array，毕竟功能不同，要写出值得比较的代码可以对 mf 复合自己 map_count 次，再变换成 reducer，然后直接在 data 数组上用 reduce 。

而且好好写 for 循环不香吗？

[kuunnnn]

这不就是延迟计算吗，lazy.js 有做这个的，lodash 好像也有类似的

[shyangs]

為什麼不用 lodash 的_.chain()

[molika]

transduce 而已 clojure/clojureScript N 年前就这么玩了 话说 js 的 map reduce 啥的竟然不是惰性的 transduce ？ 吃惊

[hupo0]

@shyangs lodash 没用过，我才知道 chain 。看了下源码，他用一个 Wrapper 的抽象，在求值前，把中间的 actions 合成一个。虽然感觉大家想做的事情一样，但实现上效率不那么高。不过 lodash 自带的东西多，容错好，本身不用太注重效率。

实际 benchmark 跑下来，速度和数组自带的方法差不多，但是内存上应该会更优越。

[hupo0]

@geelaw 比较的代码确实有的斟酌的地方，但是太难找到合适的，就粗暴点只比较了 map 和 reduce 一起用的情况。

就是不想好好写 for 循环。