使用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合约，同时在下面尝试用reducer/transducer的概念重新实现。使用transducer但使用sequence来保留当前的解析csv懒策略，同时为非遗留用户或不需要基于懒策略的实现的用户提供新的纯transducer/reducer API。

1和3基本上是相同的概念，只是3在3中用户获得了更快的底层实现的好处，也可能有其他选项。

我认为如果可能的话，3是最好的选择。

选项1和2引发了一个问题，即不试图保留向后兼容性或改善遗留用户的使用体验。

在深入探讨reducer/transducer实现的细节之前，我很想知悉核心团队对进一步探索此议题的看法。
这个议题

Answer 1

由 jonase 评论：

你能分享这个基准测试吗？在我最初编写这个库的时候我也做过一些比较，我没有看到这么大的差异。

我认为在许多情况下，懒方法是一个重要的特性，你不希望在内存中有那些千兆字节的数据。

如果我们为了性能原因增加一些非懒解析，我认为它应该是公共API的补充。

Answer 2

评论者：rickmoynihan

我同意不将数据加载到内存中是一个很大的好处，但我们不一定必须将这种流式属性与惰性/急切等同起来。

通过使用reducers/transducers，您仍然可以逐行流式处理CSV文件并且消耗恒定的内存量，例如，将行数累加不会消耗内存，即使它是急切的。同样，如果我们使用transducer通过transduce通过一个CollReduceable CSVFile对象，您可以使用sequence请求一个懒惰的序列，该序列在解析本身没有惰性税；或者，您可以通过转换到一个向量将结果加载到内存中，请求结果急切地加载。

由于没有提供这款票的基准测试结果，我感到抱歉；实际上，是Alex Miller在我与他简短讨论后建议我写这个票单的——他建议我不必要提供这些计时，因为惰性的成本是众所周知的。无论如何，我会整理用来获取计时的代码，并将其放入gist或其他地方——可能是在今天晚些时候。

Answer 3

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