我在Data.Text上做了很多阅读，但是我没有找到什么时候更喜欢Strict over Lazy，反之亦然。
我的理解是Data.Text.Strict是内存中连续字符的数据结构，而Data.Text.Lazy是一个连续字符块。
我的问题是为什么我不应该总是使用Data.Text.Lazy？似乎唯一的开销是块管理，但我不知道它是否足够明显？作为交换，当Text值变大时，连接操作可以便宜得多。
欢迎思考和见解！
答案 0 :(得分：6)
我会说使用Data.Text.Lazy会继承许多the problems of lazy IO。所以我的建议是更喜欢Strict，如果您需要按顺序处理大量数据，请使用the available streaming libraries之一。另请参阅What is pipes/conduit trying to solve。
答案 1 :(得分：6)
来自文档：
使用压缩数组列表实现Unicode文本的时间和空间高效实现。该表示适用于高性能用途和流式传输大量数据。它提供了一种操作大量文本的方法，而不需要将整个内容驻留在内存中。
由于列表主干结构的优化，某些操作（例如concat，append，reverse和cons）比Data.Text等效项具有更好的复杂性。对于其他操作，懒文本通常在严格文本的几个百分点内，但具有更好的堆使用。对于大于可用内存的数据，或者如果您有严格的内存限制，此模块将是唯一的选项。
使用压缩的Word16阵列实现Unicode文本的时间和空间效率。适用于性能关键用途，包括大数据量和高速度。
...
此模块中的大多数函数都需要融合，这意味着这些函数的管道通常最多只能分配一个Text值。
因此虽然Data.Text对于大多数用途来说已经足够了，但Data.Text.Lazy专门用于非常要处理的大量数据并且实际上无法保存的情况一下子全都在记忆中。 Data.Text一般来说效率更高一些，但对于您的应用程序来说更好，完全取决于您的用例。一个好的经验法则是从严格开始，如果您有记忆或速度问题，那么尝试使用懒惰。
答案 2 :(得分：0)
通常，用于连接数据库（postgres，redis等）的包只能提供严格的值;您从中获取的任何延迟值都是通过Data.Text.Lazy的{{1}}等函数创建的。在这种情况下，使用延迟值会增加额外的开销。这种包的一个例子是fromStrict。