懒惰I / O有什么不好？ [英] What's so bad about Lazy I/O?
问题描述
我通常听说生产代码应该避免使用惰性I / O。我的问题是，为什么？使用Lazy I / O以外的其他方法可以吗？什么使得替代方案（例如枚举方）更好？
懒惰IO有一个问题，不可预知的，因为它取决于你的程序如何消费数据 - 它的需求模式。一旦程序放弃了对资源的最后一个引用，GC将最终运行并释放该资源。
懒惰的流是非常方便的风格这就是为什么外壳管道非常有趣和流行的原因。然而，如果资源受到限制（如在高性能场景或期望放大到机器的极限）依靠GC来清理可能是一个不足的保证。
有时你必须急切地释放资源，以提高可扩展性。懒惰的IO并不意味着放弃增量处理（反过来会消耗太多的资源）？那么，我们有 foldl 为基础的处理，也就是迭代或枚举，由 奥列格Kiselyov在2000年代后期 ，并由一些基于网络的项目普及。
而不是作为懒惰的流处理数据或者在一个巨大的批处理中，我们改为对基于块的严格处理进行抽象，并在读取最后一个块时保证资源定稿。这是基于迭代器编程的本质，也是一种提供非常好的资源约束。
基于iteratee的IO的缺点在于它有一个有点尴尬的编程模型大致类似于基于事件的编程，而不是基于线程的良好控制）。在任何编程语言中，它绝对是一种先进的技术。对于绝大多数编程问题，懒惰IO完全令人满意。但是，如果您打开许多文件，或者在多个套接字上进行交谈，或者使用许多并发资源，那么迭代器（或枚举器）方法可能是有意义的。
I've generally heard that production code should avoid using Lazy I/O. My question is, why? Is it ever OK to use Lazy I/O outside of just toying around? And what makes the alternatives (e.g. enumerators) better?
Lazy IO has the problem that releasing whatever resource you have acquired is somewhat unpredictable, as it depends on how your program consumes the data -- its "demand pattern". Once your program drops the last reference to the resource, the GC will eventually run and release that resource.
Lazy streams are a very convenient style to program in. This is why shell pipes are so fun and popular.
However, if resources are constrained (as in high-performance scenarios, or production environments that expect to scale to the limits of the machine) relying on the GC to clean up can be an insufficient guarantee.
Sometimes you have to release resources eagerly, in order to improve scalability.
So what are the alternatives to lazy IO that don't mean giving up on incremental processing (which in turn would consume too many resources)? Well, we have foldl based processing, aka iteratees or enumerators, introduced by Oleg Kiselyov in the late 2000s, and since popularized by a number of networking-based projects.
Instead of processing data as lazy streams, or in one huge batch, we instead abstract over chunk-based strict processing, with guaranteed finalization of the resource once the last chunk is read. That's the essence of iteratee-based programming, and one that offers very nice resource constraints.
The downside of iteratee-based IO is that it has a somewhat awkward programming model (roughly analogous to event-based programming, versus nice thread-based control). It is definitely an advanced technique, in any programming language. And for the vast majority of programming problems, lazy IO is entirely satisfactory. However, if you will be opening many files, or talking on many sockets, or otherwise using many simultaneous resources, an iteratee (or enumerator) approach might make sense.
这篇关于懒惰I / O有什么不好？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
