There are two senses in which deepseq can be overkill: 1. The structure was already strict, and deepseq just forces another no-op traversal of the entire structure. This hypothetically affects seq too, although seq is quite cheap so it's not a problem. 2. deepseq evaluates too much, when it was actually sufficient only to force parts of the structure, e.g. the spine of a list. This is less common for the common use-cases of deepseq; e.g. if I want to force pending exceptions I am usually interested in all exceptions in a (finite) data structure; a space leak may be due to an errant closure---if I don't know which it is, deepseq will force all of them, ditto with work in parallel programs. Certainly there will be cases where you will want snip evaluation at some point, but that is somewhat difficult to encode as a typeclass, since the criterion varies from structure to structure. (Though, perhaps, this structure would be useful: data Indirection a = Indirection a class DeepSeq Indirection rnf _ = () ) Cheers, Edward Excerpts from Joachim Breitner's message of Mon Jan 07 04:06:35 -0800 2013:
Dear Haskellers,
I’m wondering if the use of deepseq to avoid unwanted lazyness might be a too large hammer in some use cases. Therefore, I’m looking for real world programs with ample use of deepseq, and ideally easy ways to test performance (so preferably no GUI applications).
I’ll try to find out, by runtime observerations, which of the calls ot deepseq could be replaced by id, seq, or „shallow seqs“ that, for example, calls seq on the elements of a tuple.
Thanks, Joachim