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  .                                         457296    3341600    TA
  P  .{...}                                    698872    5220200    TA
  P  .{.{...}..}                               954252    6063164    TA
  P  .{.{...{.}}..}                           1243156    6572740    TA
  P  .{.{...{.{.#..}}}..{..}}                 1452016    8829248    TA
  P  .{.{..{.}.{.{.{.}#..{.}}}}..{..{.}}}      319744   10577588    TA
  P  .{.{..{.}.{.{.{.}#..{.}}}}..{..{.}}}      159284    8870360    TA
  P  .{.{..{.}.{.{.{.}#..{.}}}}..{..{.}}}      150004    8826904    TA
  P  .{.{..{.}.{.{.{.}#..{.}}}}..{..{.}}}      190012    8748076    TA
  P  .{.{..{.}.{.{.{.}#..{.}}}}..{..{.}}}      128232    8867404    TA

A few comments are in order:

• You can see the space leak as a steady, substantial growth in the heap size, from N=0 through N=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.