#11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari): I've pushed a simple approach to avoid `build`-based list desugaring for large lists to Phab:D2007. Here we simply threshold on the list length. I have a few concerns about this approach, * This threshold introduces a "performance cliff", where users will suddenly see drastically different performance characteristics as their literal lists grow. * There isn't really a good way to choose this size. Ideally we'd want a smaller threshold with larger consumers and vice-versa, but we have no way of knowing what will be consuming our list in the desugaring. From a runtime performance perspective, applying `build` more liberally should rarely hurt (it can only expose further optimization opportunities; if no fusion is possible it will eventually get rule-rewritten back to a list) Consequently, the threshold we introduce here is a bit concerning since we are limiting contexts in which we'll use `build`, potentially hiding optimizations. Regardless, `nofib` shows no change in allocations after this change, so it at very least doesn't hurt any of the cases there. Moreover, it shows a 30% reduction in compiler allocations in `T9961` (from 745044392 to 745044392 bytes). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11707#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler