#9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata):
I suspect that adding -O2 to libraries and compiler (we would have to do both) would make validate lower, but I don't know how much; feel free to measure it. I do think validate is too slow already, though, and we should be finding ways to speed it up.
I changed the builder for ghcspeed to set `Validating=YES`, and the time to run `make` was reduced by ¼. I didn’t measure the time for a whole validate run, I guess I’ll do that separately. But setting that changes more than just `GhcLibHcOpts`, e.g. it disables split objects (increasing binary sizes by a factor of 3.5). Allocation of nofib benchmarks wobble a bit, but significat changes are only on the increasing side (fish, +5%), so for nofib, the release settings seem to be better than the validate setting. (good!) The allocation number of #4801’s test case actually decreases by 4.7%. In total, 7 test cases now get *better* allocation numbers, while only `haddock.base` degrades by more than 1%. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9315#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler