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.
- rGHC Glasgow Haskell Compiler
Lint Warnings Excuse: Linty Severity Location Code Message Warning compiler/types/TyCoRep.hs:2839 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2840 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2841 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2844 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2850 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2851 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2852 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2853 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2856 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2857 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2859 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2862 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2863 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2867 TXT3 Line Too Long Warning compiler/types/TyCoRep.hs:2877 TXT3 Line Too Long
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
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.