[Haskell-cafe] Code runs 7x FASTER with profiling

[Sven Panne]

2017-12-07 22:25 GMT+01:00 Neil Mayhew <neil_mayhew at users.sourceforge.net>:

> [...] 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 pattern
> a local definition of parseFilename, why isn’t it treated as a CAF that’s
> evaluated only once (‘floated to the top level’)?
>
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. :-)



> Enabling profiling shouldn’t change the meaning of a program.
>
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.


> 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.)
>
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.

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171208/b98983ee/attachment.html>