Output of leaky as instrumented with seqaid

The following shows the output of seqaid with leaky. You would see something close to this if you ran leaky with default configuration. It is a wee bit contrived, as I sweep NFDataN N value to a fixed depth, and then the fixed (hand-optimised) Pattern is developed by replaying iterated shrinkPat in reverse. But it does illustrate the sorts of effects possible, once seqaid has an optimiser.

Using NFDataN.forcen N

                                       live      alloc  type
  N  0                               357828    3350236    TA
  N  1                               686376    3316512    TA
  N  2                               909104    4942636    TA
  N  3                              1121052    4979364    TA
  N  4                              1301872    5560432    TA
  N  5                              1609760   53440684    TA
  N  6                               151460   54431296    TA
  N  7                               139240   53374284    TA
  N  8                               129440   53405380    TA

Using NFDataP.forcep P:

                                       live      alloc  type
 P  .                                227756    1769792    TA
 P  (.                 ..     )      296620    3060904    TA
 P  ((..  .           )..     )      360508    4908612    TA
 P  ((..  (.         ))..     )      421472    5852124    TA
 P  ((..  ((.  ...  ))).(..  ))      521860    9556760    TA
 P  ((.(.)(((.)..(.)))).(.(.)))      607100   11270660    TA
 P  ((!(!)(((!).!(!))))!(!(!)))     1925776    2392040    TA
 P  ((!(!)(((!).!(!))))!(!(!)))     1529652   10297768    TA
 P  ((!(!)(((!).!(!))))!(!(!)))     1249900    2393836    TA
 P  ((!(!)(((!).!(!))))!(!(!)))      690336   13244056    TA
 P  ((!(!)(((!).!(!))))!(!(!)))      212580   13974556    TA
 P  ((!(!)(((!).!(!))))!(!(!)))      216936   11284560    TA

A sort of commentary on the change history is on a separate page.

Remarks

• You can see the space leak as a steady, substantial growth in the heap size, from N equal 0 through 5, and again in the first five pattern lines.
• You can see the first large, strict blobs get hit at a depth of 5 (with forcen).
• Unfortunately :) it is not until a depth of 6 that the leak can be plugged. (Well, you can plug it without forcing the spine, using let-lifting, but seqaid doesn't do that yet.) So NFDataN is not a feasible solution for this leak.
• NFDataP.forcep successfully plugs the leak without hitting the big strict blobs.
• This output doesn't show how NFData would perform worse, but for large N there is additional penalty due to the presence of some long lists (not strict, but deep) in the state.