#10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata):
Has there been any testing to determine the effect on the speed of compiled code whose compilation was significantly speeded up? The Phab only mentions nofib times, whose compile times aren't effected anyway.
No, unfortunately we lack good benchmarks for this. `haskell-src-exts` does not define any, and even if it would, there is little infrastructure to run and compare such benchmarks easily. Again intuition, but: Those cases that blew up tend to be large and complex, so the chances that everything fits together in a way for Call Arity to succeed are small.
Hard-coding the limit of 25 seems rash when there's only one data point (haskell-src-exts). This should probably be configurable at run-time until its had a lot more use out in the wild to see if this really is the best value in practice.
People were asking for a fix that can go into 7.10.2, so this is a rash move. I believe the limit is still higher than the lowest reasonable limit, so we should be fine – but again without evidence. Also, it’s always annoying to add flags-dependent values to pure code with no `DynFlags` around, as it is the case here. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10293#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler