Simon Peyton Jones <simo...@microsoft.com> writes: > | tests/alloc/haddock.Cabal 11811321368 + 6.40% 12567003040 > | bytes > | tests/alloc/haddock.compiler 60211764264 + 7.39% > | 64658444232 bytes > | > | The haddock stats changes are probably genuine, I assume, but the > | expected value in all.T should be updated. > | > > I'm sad about this. My changes should have had no visible performance > impact. But I'm not set up to dig into why this one patch might have > had such large impact on Haddock. Presumably it's not Haddock per-se > but perhaps the GHC session that it invokes. > > I am not sure what to do... I'm quite reluctant to cause a 7% > regression in allocation without investigation. I suppose I or someone > should investigate before-and-after, but I don't have time to do that > this week. > > If someone felt able to have a go, that'd be fantastic. Otherwise > let's at least make a ticket. > > For the record, the series of patches, one of which presumably causes > the regression, is below. Bisecting to the right one would be very > helpful -- but you have to apply the final one (haddock-update) first. > I've opened #12191 to track this. I'll try to get to it although I have a friend visiting at the moment so time will be a bit tight until Thursday.
Cheers, - Ben
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
