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

[hupo0]

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

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

[hupo0]

@musi 所以用了似乎，实际上，如果要提高代码的表达，很多时候不会选择把逻辑都挤在一个循环里，至少我是这样的。

[civet]

@molika js 不是天生就是为函数式编程服务的，而是社区各路大神引领了这种潮流，实际上就是底层没实现，写法先出现

[Rocketer]

js 聊性能的意义不是特别大，毕竟主要用途是前端，数组大小不会超过 100 条。相比较而言，节约代码提高开发效率更受欢迎。

真要用在后端处理大数据，那还是像 Python 那样用 C 做类库，让 js 调用吧，纯 js 再努力也提升不了太多

[darknoll]

没有意义，前端无需注重效率，数据量大了应该是分页之类的，反正 Iterable 对象我都用 for of，我也知道 for 循环速度最快。

[wxsm]

从算法角度来说，1 次循环，3 次循环，n 次循环，时间复杂度都是 O(n)，并没有实质区别。

[cenbiq]

不禁感慨，C#的 Linq 真是有远见

[hupo0]

@cenbiq 看看所谓的 Zero cost abstraction - 刘雨培的文章 - 知乎
https://zhuanlan.zhihu.com/p/24975048
吐槽 C# - 刘雨培的文章 - 知乎
https://zhuanlan.zhihu.com/p/30653282

参考这两篇回答，17 年的 C#还没有对 linq 进行优化。虽然用迭代器也是相当于只遍历一遍，但是迭代器“调用”迭代器的过程还是会有额外的性能损耗。完美一点的是，能做到跟 C++一样，把迭代器 yield 的逻辑内联到一个循环里。

想来 no-stream 的做法，是函数调用层面，把"yield"部分通过函数包函数的方式合并到一个循环里。虽然也是有函数调用方面的开销，但目前来看，会比 JS 的 Generator 还节省性能些。

从现有的 C++和 Rust 的案例来看，其实正道还是 iterator，似乎这样的结构更容易优化。linq 也是在正道上，只是需要引擎对这部分进行优化。与之对应的是 JS 的 Generator 。可惜就是目前他们还很拉胯。

[cenbiq]

@hupo0 用 yield 肯定会产生额外性能损耗嘛。js 是有 Generator 但是我接触下来应用很少，反观 C# IEnumerable 和 IEnumerator 几乎是必不可少的东西，no-stream 类似 rx 管道吧，收集操作最后一次循环执行，无非就是这些方法了。
不过还是得夸 linq，想当初换到 js 和 java 各种不习惯。