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.