<div dir="ltr"><div><div>Alternatively, just use "return $! ", which has the same effect as seq-ing, and is generally a good practice (unless you want to be explicitly lazy). See <a href="http://johantibell.com/files/haskell-performance-patterns.html">http://johantibell.com/files/haskell-performance-patterns.html</a>.<br><br></div>the-thing +RTS -s (with GHC 8)<br><br> 3,965,758,088 bytes allocated in the heap<br> 46,006,592 bytes copied during GC<br> 207,792 bytes maximum residency (5 sample(s)) <---- down to 200K from 1.5G<br> 182,864 bytes maximum slop<br> 8 MB total memory in use (0 MB lost due to fragmentation)<br><br></div>Robin<br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-26 12:42 GMT+01:00 Johannes Waldmann <span dir="ltr"><<a href="mailto:johannes.waldmann@htwk-leipzig.de" target="_blank">johannes.waldmann@htwk-leipzig.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for pointing out this (Knuth's) nice test case.<br>
I should use this as an exam question ...<br>
<br>
Allocation and run-time can be reduced<br>
by replacing return (x3' + x4')<br>
with let x = (x3' + x4') in x `seq` return x<br>
And, modifySTRef' *does* help.<br>
<br>
I *do* notice a regression<br>
(for the seq-ed and primed version)<br>
<br>
ghc-8.0.2 : 2.6 GB alloc, 2.3 sec<br>
ghc-6.10.4: 2.0 GB alloc, 1.7 sec<br>
<br>
(measured on X5365 @ 3.00GHz )<br>
<br>
Numbers are for total allocation,<br>
residency is small (it runs with +RTS -H10k -A10k<br>
but then the number of GCs goes up)<br>
<br>
- J.<br>
______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br></div>