<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-12-07 22:25 GMT+01:00 Neil Mayhew <span dir="ltr"><<a href="mailto:neil_mayhew@users.sourceforge.net" target="_blank">neil_mayhew@users.sourceforge.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="m_4395122790402357441markdown-here-wrapper" style="font-family:Ubuntu,Cantarell,Deja Vu Sans,sans-serif;font-size:10pt"><span class="">
      <p style="margin:0px 0px 1.2em!important"><span style="font-size:10pt">[...] The question
        remains, however: why doesn’t the ghc optimizer spot this fairly
        obvious loop-invariant in the non-profiled build when it does
        manage to spot it in the profiled one? In other words, when I
        make </span><code style="font-size:0.95em;font-family:Consolas,Inconsolata,"Deja Vu Sans Mono",Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">pattern</code><span style="font-size:10pt">
        a local definition of </span><code style="font-size:0.95em;font-family:Consolas,Inconsolata,"Deja Vu Sans Mono",Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">parseFilename</code><span style="font-size:10pt">,
        why isn’t it treated as a CAF that’s evaluated only once
        (‘floated to the top level’)?</span></p></span></div></div></blockquote><div>Because making something a CAF is not always an optimization: If your evaluated CAF uses e.g. hundreds of MB it might be preferable to *not* have it as a CAF, but to to recompute it instead. If I haven't missed something recently, CAFs can't be garbage collected, but I would be happy to be corrected here. :-)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="m_4395122790402357441markdown-here-wrapper" style="font-family:Ubuntu,Cantarell,Deja Vu Sans,sans-serif;font-size:10pt"><span class=""><p style="margin:0px 0px 1.2em!important"><span style="font-size:10pt"> Enabling profiling shouldn’t
        change the meaning of a program.</span></p></span></div></div></blockquote><div>It doesn't change the meaning, that would really be a desaster, it just changes the performance characteristics. This is still not nice, but not much different from using different levels of optimization: Doing or not doing e.g. strictness analysis might change the space complexity etc.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="m_4395122790402357441markdown-here-wrapper" style="font-family:Ubuntu,Cantarell,Deja Vu Sans,sans-serif;font-size:10pt">
      <p style="margin:0px 0px 1.2em!important">I remember back in
        the day having to be careful with regexes in Python to make sure
        they were always precompiled outside of loops and functions, but
        one of the nice things about Haskell is that one can usually let
        the compiler take care of this. (Nowadays Python gets around
        this by caching compiled regexes, but I prefer Haskell’s
        statically-optimized approach.)</p></div></div></blockquote><div>I think totally relying on the compiler for performance is a common misconception, because things are often more tricky than initially thought. In our example: Time vs. space tradeoff, and there is no universally "right" solution.</div><div><br></div><div>Cheers,</div><div>   S.</div></div></div></div>