typechecker significant slow-down

[jurgenvinju]

Describe the bug

• type-checking the Rascal library code of rascal-eclipse used to take 9 minutes on github actions, via mvn compile;
• with the current release it takes 54 minutes to do the same;
• similar observations can be made for compiling the standard library in the rascal project;

Given that the interpreter did not change much in the past year, we could assume that it is an algorithmic effect in the execution of the Rascal typepal collector or in the typepal solver.

So running the Rascal profiler seems to best first step to take, to see if we have new hotspots in the Rascal code of the type-checker.

Note that the impact of the problem is excacerbated by usethesource/rascal-maven-plugin#5 which causes the type-checker to run again and again during a Github Action job. However, this effect was not included in the timings above 9--54 is an honest comparison between two runs of the type-checker on a real library.

[jurgenvinju]

Still there could also be other factors causing this slow-down:

• Java 11 JRE - a big change in the context
• GitHub Actions hardware/virtual machine configuration is out of our controle
• Searching files in |lib://projectName| is used much more and could cause long search times in jar files underneath

[DavyLandman]

The first two could easily be figured out right?

Rascal core is not depending on java 11 features, so it could without a problem be loaded in a java 8 rascal jar? And use that for the same typecheck operation?

Similarly, if you run locally, we could rule out great interactions from GitHub actions. But I want to say that there's a small chance of that causing a big change. Like a few minutes difference: sure.

[jurgenvinju]

3 hours or 2 hours; https://github.com/usethesource/rascal/actions we should be able to explain the differences between these last few runs with big differences in efficiency.

[DavyLandman]

Yup, but does it also run much slower on your own laptop?

[jurgenvinju]

Yes that too. Rodin just found the cause of that. No tpl file was ever reused.

[PaulKlint]

In the end these were path issues with various accumulating/overlapping causes. This is now probably fixed but let's leave this open until we can confirm that the slowdown has disappeared.