
Has anybody filed a bug about this yet? I think we really should. I recently observed a similar behaviour in code of a client. It looked like main = do l <- getSomeList let m = buildExpensiveHashMap l for_ l $ \element -> do print (... lookup l m ...) And it inlined the `buildExpensiveHashMap`, making the whole thing 100x slower. A bang on `m` fixed it to keep it outside the loop, but I found it weird that GHC considered that expression cheap enough to inline. Niklas On 09/12/2017 00:59, Brandon Allbery wrote:
On Fri, Dec 8, 2017 at 9:18 AM, Neil Mayhew
mailto:neil_mayhew@users.sourceforge.net> wrote: Good point. Having great optimization isn’t a justification for complete mental laziness on the part of the programmer! However, I did find the behaviour in this case surprising and unintuitive, given ghc’s usual ability to optimize things, and having it change on me when I enabled profiling left me wondering where to go next. The code I presented here is considerably simplified from the original program, and represents a lot of work already expended trying to get to the root of the problem.
This is actually why I (and likely SPJ) am inclined to consider it a bug; while it might be arguable as Sven does, the counterintuitive effect when you turn on profiling suggests that it's not intended or expected. (Although maybe it should be; the intuition is "profiling disables optimization" but what it really does is a bit more subtle than that overly simplistic notion.)
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com mailto:allbery.b@gmail.com ballbery@sinenomine.net mailto:ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.