leaky-0.1.0.0: HTML/output.html
<!DOCTYPE html>
<html>
<head>
<title>Leaky : Output Under Seqaid</title>
<link rel="stylesheet" href="style.css" />
</head>
<body>
<!--body style="width: 800px;"-->
<div class="main">
<h3 style="margin-top: 50px; margin-bottom: 30px; color: #666;">
Output of <tt>leaky</tt> as instrumented with <tt>seqaid</tt>
</h3>
The following shows the output of <a href="http://hackage.haskell.org/package/seqaid"><tt>seqaid</tt></a> with <a href="http://hackage.haskell.org/package/leaky"><tt>leaky</tt></a>.
You would see something close to this if you ran <tt>leaky</tt> with default configuration.
It is a wee bit contrived, as I sweep <a href="http://hackage.haskell.org/package/deepseq-bounded/docs/Control-DeepSeq-Bounded-NFDataN.html"><tt>NFDataN</tt></a> <tt><em>N</em></tt> value to a fixed depth, and then the fixed (hand-optimised) <a href="http://hackage.haskell.org/package/deepseq-bounded/docs/Control-DeepSeq-Bounded-Pattern.html"><tt>Pattern</tt></a> is developed by replaying iterated <a href="https://hackage.haskell.org/package/deepseq-bounded/docs/Control-DeepSeq-Bounded-PatAlg.html#v:shrinkPat"><tt>shrinkPat</tt></a> in reverse.
But it does illustrate the sorts of effects possible, once <tt>seqaid</tt> has an optimiser.
<p>
Using <tt>NFDataN.forcen <em>N</em></tt>:
<pre>
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
</pre>
<p>
Using <tt>NFDataP.forcep <em>P</em></tt>:
<pre>
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
</pre>
<p>
A few comments are in order:
<ul>
<li>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.
<li>You can see the first large, strict blobs get hit at a depth of 5 (with <tt>forcen</tt>).
<li>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 <tt>seqaid</tt> doesn't do that yet.) So <tt>NFDataN</tt> is not a feasible solution for this leak.
<li><tt>NFDataP.forcep</tt> successfully plugs the leak without hitting the big strict blobs.
<li>This output doesn't show how <tt>NFData</tt> 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.
<!--<li>It may appear there is still a slight leak in the heap, with the final pattern, but if the run is extended, this space is reclaimed periodically.
I don't quite understand this, since I am using <tt>performGC</tt> before each stats line is printed, but the fact is there is no longitudinal net growth.
(Oops, I don't see it in this paste anyways...).-->
</ul>
<div class="footer">
Andrew Seniuk 2014
<br>
<tt>rasfar@gmail.com</tt>
</div>
</div>
<script language="javascript">
function toggle(id1){
var ele_s = document.getElementById(id1+"s");
var ele_h = document.getElementById(id1+"h");
var ele = document.getElementById(id1);
if( ele.style.display == "inline-block" ){
ele.style.display = "none";
ele_s.style.display = "inline-block";
ele_h.style.display = "none";
}else{
ele.style.display = "inline-block";
ele_s.style.display = "none";
ele_h.style.display = "block";
}
}
</script>
</body>
</html>