Closed rssh closed 2 years ago
long-compilation-example.tar.gz
full sbt project
Performance seems to have regressed between 3.0.1 and 3.0.2:
$ time scalac -3.0.1 i13565.scala
real 0m5.204s
user 0m14.325s
sys 0m0.461s
$ time scalac -3.0.2 i13565.scala
real 2m35.770s
user 2m45.828s
sys 0m0.924s
~I do not think this needs minimisation - it is a stress test (although it should not be stressing)~
Although would be good to try and track the growth of the problem over reducing cases
Performance seems to have regressed between 3.0.1 and 3.0.2:
$ time scalac -3.0.1 i13565.scala real 0m5.204s user 0m14.325s sys 0m0.461s $ time scalac -3.0.2 i13565.scala real 2m35.770s user 2m45.828s sys 0m0.924s
I recognise those command line options! 😄
I'm pretty sure #13030 is what changed that.
There's a number of places in the space engine where work is done multiple times, some of which I've removed (in master) while fixing other issues but others where the result is less easily retrainable. Meaning we could memoise them, but then we might start breaching our memory budget. I'll play with the case and see what I can see.
minimization is problematic because we can lose visible slowdown during this. I.e. I'm pretty sure, that with 3 case classes instead of 63 this will be fast. How we can detect a 'minimal limit' when performance difference becomes visible?
So 63 classes takes (on your machine) 2:30 minutes. Perhaps we can write out 4 or 5 incremental steps on that (e.g. 8 -> 16 -> 32 -> 64 classes), and assert on by how much compilation speed increases. As in, linear growth rather than exponential, perhaps.
Compiler version
3.1.0-RC2
Minimized example
Output
Expectation
compilation speed should be significantly faster.