Performance Profiling

Maybe this should be a running meta-issue. I've noticed that some of the lambda calculus modules are slow, so I decided to look at build times. Here are the 15 slowest (of ~50) from me building locally, which happens to coincide with a cutoff of 5 seconds:

Cslib.Languages.LambdaCalculus.LocallyNameless.Fsub.Subtype (11s)
Cslib.Logics.LinearLogic.CLL.Basic (10s)
Cslib.Foundations.Data.FinFun (10s)
Cslib.Languages.LambdaCalculus.LocallyNameless.Stlc.Basic (9.1s)
Cslib.Languages.LambdaCalculus.LocallyNameless.Fsub.WellFormed (8.8s)
Cslib.Languages.LambdaCalculus.LocallyNameless.Fsub.Typing (8.5s)
Cslib.Logics.LinearLogic.CLL.PhaseSemantics.Basic (8.4s)
Cslib.Languages.LambdaCalculus.LocallyNameless.Fsub.Opening (8.3s)
Cslib.Foundations.Data.OmegaSequence.Init (8.0s)
Cslib.Foundations.Lint.Basic (7.2s)
Cslib.Foundations.Semantics.LTS.Bisimulation (6.8s)
Cslib.Foundations.Data.OmegaSequence.Flatten (6.0s)
Cslib.Languages.LambdaCalculus.LocallyNameless.Fsub.Safety (5.7s)
Cslib.Languages.CCS.BehaviouralTheory (5.7s)
Cslib.Languages.LambdaCalculus.LocallyNameless.Untyped.FullBetaConfluence (5.2s)

I have a guess at some issues in Cslib.Languages.LambdaCalculus.LocallyNameless related to grind rules for typing contexts. Some others may just be longer files, there is not necessarily something wrong in all cases.

Start by reproducing the local build timings for the listed Cslib modules, then inspect Cslib.Languages.LambdaCalculus.LocallyNameless and its grind rules for typing contexts. Compare the slower modules with longer-file cases and determine whether a specific cause or actionable improvement can be identified; the issue does not define a completion target.