Speed up core size and core stats
Needs RevisionPublic

Authored by dfeuer on Apr 21 2017, 4:02 PM.

Details

Reviewers
bgamari
austin
Summary

When calculating core size and core stats, we previously
calculated sizes/stats for sub-parts and then added them.
It should be faster to thread an accumulator through.

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Branch
wip/faster-stats
Lint
Lint WarningsExcuse: Linty
SeverityLocationCodeMessage
Warningcompiler/types/TyCoRep.hs:2839TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2840TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2841TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2844TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2850TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2851TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2852TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2853TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2856TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2857TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2859TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2862TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2863TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2867TXT3Line Too Long
Warningcompiler/types/TyCoRep.hs:2877TXT3Line Too Long
Unit
No Unit Test Coverage
Build Status
Buildable 16529
Build 29968: [GHC] Linux/amd64: Patch building
Build 29967: [GHC] OSX/amd64: Continuous Integration
Build 29966: [GHC] Windows/amd64: Continuous Integration
Build 29965: arc lint + arc unit
dfeuer created this revision.Apr 21 2017, 4:02 PM

I don't understand why this would be faster, could you explain?

As far as I know all these functions are only used when compiling with -v/-dshow-passes, so they aren't terribly performance-critical. IIRC after 09d70107a there wasn't any remaining noticeable performance difference between using -v and not.

dfeuer planned changes to this revision.Apr 21 2017, 4:42 PM

I don't understand why this would be faster, could you explain?

As far as I know all these functions are only used when compiling with -v/-dshow-passes, so they aren't terribly performance-critical. IIRC after 09d70107a there wasn't any remaining noticeable performance difference between using -v and not.

Well, it means not having to stack up all the calculations; we can perform some of them as we go. That is, we only need to build up on one side of each node. But you're right; if this isn't that important in practice, it's not worth the bother. However, it might be worth the bother for exprSize, which is used by the simplifier.

dfeuer updated this revision to Diff 13036.Jul 5 2017, 10:29 PM
  • Silly
  • Merge branch 'wip/faster-stats' of git.haskell.org:ghc into wip/faster-stats
dfeuer updated this revision to Diff 13037.Jul 6 2017, 12:45 AM
  • Add type signature
bgamari edited edge metadata.Jul 7 2017, 10:04 AM

This doesn't yet validate and it would be nice to see some characterization of the speedup, if any. Afterall, the new scheme doesn't exactly help readability :)

bgamari requested changes to this revision.Jul 7 2017, 10:04 AM
This revision now requires changes to proceed.Jul 7 2017, 10:04 AM

No, I'm not seeing what I want yet. Will investigate further.

austin resigned from this revision.Nov 9 2017, 11:36 AM