使用Reducer/Transducer优化性能和资源管理

Question

在使用clojure.data.csv库时，一个问题就是它基于懒序列构建，这会导致处理大量数据时的效率低下。例如，在我机器上，即使没有进行任何转换，对1GB CSV数据的基准解析也花了大约50秒，而其他在JVM上可用的解析器可以在不到4秒内解析这个数量的数据。

我想讨论如何将clojure.data.csv迁移到使用Reducer/Transducer模型，以提高性能和资源管理。概括地说，我认为有几个选择：

1. 作为c.d.csv中的次要替代API实现，保留现有的API和实现，以便为遗留用户提供支持。
2. 完全替换API，不尝试保留向后兼容性。
3. 保留相同的公共API合约，同时在尝试在底层使用Reducers/Transducers重新实现它。在底层使用transducers，但使用sequence来保留当前parse-csv的懒序列合约，同时为非遗留用户或不需要基于懒序列实现的用户提供新的纯transducer/reducer基于API。

1和3实际上是同一个想法，但是3中用户可以享受更快底层实现的好处，也可能有其他选择。

我认为如果可行，3将是最佳选择。

选择1和2引发了一个问题，即在向后兼容性或改善遗留用户体验方面不做出尝试。

在深入讨论Reducer/Transducer实现细节之前，我很想了解一下核心团队如何看待进一步探索这一点。
这个

Answer 1

jonase的评论：

能否分享这份基准测试结果？在我最初编写这个库时，我进行了比较，并没有看到如此大的差异。

我认为在许多情况下，懒加载方式是一个重要的特性，尤其是在你不想在内存中保留所有这些千兆字节数据时。

如果我们出于性能考虑添加一些非懒惰解析，我认为这些应该是对公共API的增加。

Answer 2

评论者：rickmoynihan

我同意不将数据加载到内存中是一个巨大的好处，但我们不应该必然地将这种流属性与懒惰/急切关联起来。

通过使用reducers/transducers，您仍然可以逐行流过CSV文件并消耗恒定的内存量，例如，将行数减少到总数不会消耗内存，即使它是急切的。同样，如果您使用transducer和可通过CollReduce的CSVFile对象执行transduce，则可以使用sequence请求一个懒惰序列的结果，其中解析本身没有支付懒惰税；或者，您也可以请求通过将结果转换为向量来急切加载结果。

对于没有与这张票一起提供任何基准测试结果表示歉意；实际上，是Alex Miller建议我在与他简短地在Slack上讨论后编写这张票据 - 他的建议是，我不需要提供计时，因为懒惰的成本是众所周知的。无论如何，我会整理出用来获取计时数据的代码，并放入一个gist或其他地方 - 也许今天稍后。

Answer 3

参考： https://clojure.atlassian.net/browse/DCSV-15 (由rickmoynihan报告)