#16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):
with full-laziness we float out the creation of the [0..n] list,
This particular thing is quite delicate. Consider {{{ f xs = map (\x -> foo x [1..100]) xs }}} Should we float that `[1..100]` out to top level, and share it among all the calls that `map` makes? Or should we reconstruct it on every call. In the latter case we might be able to fuse it with the consumer (perhaps we inline `foo`). But even if we fuse away the list we might still allocate heap objects for `I# 1`, `I# 2`, ... `I# 100`, for each element of `xs` rather sharing those values between all those calls. Or, perhaps, we get to fuse away those `I#` boxes too! It all depends on `foo`. I don't really have a good answer here. Sometimes full laziness is a win, sometimes not. There is more discussion in #7206. I'd love someone to work on this a bit. Somehow we should do better than we are doing. PS: I have no idea why the particular commit that made this test worse did make it worse; that might be worth investigation. Another thing that would be v useful is to distil the example into a standalone test case. `vector` is a complicated library, but David's analysis above isolates the issue well. Maybe someone can turn that into a repro case? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16004#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler