Efficiency of the code generator

[Rewbert]

Running stack test --profile shows that while the tests are executing, more than 36% of the time is spent in the mainland module, which is responsible for generating the C code. Since every test is generating code it makes sense that it would show up in the profile, but I am not sure if this is a lot or not. I would generally expect many of the other things we do to take a lot of time (writing files, moving files, running the interpreter etc).

It would be interesting, when we have time, to see if we can figure out exactly why so much time is spent generating C code.

[Rewbert]

COST CENTRE        MODULE                    SRC                                            %time %alloc

best.be.lineLoc    Text.PrettyPrint.Mainland Text/PrettyPrint/Mainland.hs:(609,9)-(618,57)   11.9    3.9
best.be            Text.PrettyPrint.Mainland Text/PrettyPrint/Mainland.hs:(581,5)-(626,33)   10.5   28.9
doMake             Test.Ssm.Build            test/lib/Test/Ssm/Build.hs:(65,1)-(79,51)        6.6    1.5
displayS.go        Text.PrettyPrint.Mainland Text/PrettyPrint/Mainland.hs:(675,5)-(681,67)    4.4   14.6
MAIN               MAIN                      <built-in>                                       3.7    0.2
flatten            Text.PrettyPrint.Mainland Text/PrettyPrint/Mainland.hs:(344,1)-(355,44)    3.2    4.0
>>=.\.(...)        Test.QuickCheck.Gen       Test/QuickCheck/Gen.hs:68:15-35                  3.2    1.2
randomIvalInteger  System.Random             System/Random.hs:(468,1)-(489,76)                2.3    2.5
primitive          Control.Monad.Primitive   Control/Monad/Primitive.hs:97:3-16               2.2    1.4
pprPrec            Language.C.Pretty         Language/C/Pretty.hs:(788,5)-(1009,48)           2.2    1.9
best.be.pragma     Text.PrettyPrint.Mainland Text/PrettyPrint/Mainland.hs:(625,9)-(626,33)    1.9    0.1
doVg               Test.Ssm.Build            test/lib/Test/Ssm/Build.hs:(88,1)-(98,72)        1.9    0.8
<>                 Text.PrettyPrint.Mainland Text/PrettyPrint/Mainland.hs:128:5-14            1.8    1.9
eval               LowInterpreter            edsl/LowInterpreter.hs:(575,1)-(601,49)          1.7    1.9
createBlock256     System.Random.TF.Gen      src/System/Random/TF/Gen.hs:(41,1)-(47,26)       1.4    2.1
mash               System.Random.TF.Gen      src/System/Random/TF/Gen.hs:(117,1)-(126,29)     1.3    0.8
sleep              Test.Hspec.Core.Clock     src/Test/Hspec/Core/Clock.hs:33:1-36             1.3    0.0
text               Text.PrettyPrint.Mainland Text/PrettyPrint/Mainland.hs:143:1-28            1.2    0.4
best.better        Text.PrettyPrint.Mainland Text/PrettyPrint/Mainland.hs:(629,5)-(630,42)    1.1    2.3
tfGenSplit         System.Random.TF.Gen      src/System/Random/TF/Gen.hs:(166,1)-(173,35)     1.1    2.2
pprLoc             Language.C.Pretty         Language/C/Pretty.hs:31:1-34                     0.8    1.3
best.updatePos     Text.PrettyPrint.Mainland Text/PrettyPrint/Mainland.hs:(643,5)-(645,41)    0.7    1.6
reportFileOnFail   Test.Ssm.Report           test/lib/Test/Ssm/Report.hs:(95,1)-(103,48)      0.6    1.2
mkTFGen            System.Random.TF.Gen      src/System/Random/TF/Gen.hs:(133,1)-(134,36)     0.5    2.1
randomIvalIntegral System.Random             System/Random.hs:462:1-71                        0.5    1.1
tfGenNext'         System.Random.TF.Gen      src/System/Random/TF/Gen.hs:(157,1)-(163,32)     0.3    1.5

[j-hui]

This might not be a huge issue; as we start doing more with the compiler itself, the time spent on pretty-printing the C code may eventually be overshadowed the time spent in the rest of the compiler.

And while this compile time adds up for our test suites, it's still relatively small, so it shouldn't impact usability for language users.