-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Make compilationUnitInfo of TastyLoader lazy
#24604
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This PR introduces 2 new experimental options: `-Ybest-effort` and `-Ywith-best-effort-tasty`. It also introduces the Best Effort TASTy format (BETASTy), a TASTy aligned file format able to hold some errored trees. Behaviour of the options and the format is documented as part of this PR in the `best-effort-compilation.md` docs file. `-Ybest-effort` allows to create .betasty files in a failing compilation, while `-Ywith-best-effort-tasty` allows to read them in subsequent compilations, so that we can get information needed for IDEs from broken modules, and modules depending on them. It is worth noting that these compilation depending on Betty will never reach transform phases, and will never produce any artifacts other then betasty and semanticdb. My overall aim was to be able to handle as many cases, with little as little maintainance necessary as possible. This is for example why pretty much the only required phases are Parser and Typer - they are enough for, as far as I know, all necessary metals completions and I did not find any issues with setting their products (best effort tasty files) as dependencies. Requiring, for example, PostTyper, would require for the errored trees to be able to somehow pass through that phase, meaning a large investment from me into working the existing known error cases through there (muddling the codebase in the process) and possibly from the maintainers working on both Typer (to be able to produce „correct” error trees) and PostTyper (to be able to consume „correct” errored trees), which would obviously make the entire initiative dreadful. This is also why any tests are able to be put into a blacklist file, in case something changes and a neg test will not pass, or a new test will be added as part of issue fix that does not play well with the best-effort features.
d072c42 to
4140995
Compare
For a hello world program, this still feels like a lot. At least, it is better than 641 files. |
Yes, I think it would be interesting to try to reduce that number further in the future. Here is what we currently load for hello world |
I guess we are currently loading anything reachable from |
|
When the scale allows it, you should base the Y axis on 0. As is, the graph is misleading. (and it's a shame because it's genuinely better). |


This PR addresses a performance regression recently found between Scala 3.7.4 and 3.8.0. The root cause is that we unzip many Tasty files that we don’t actually need, because
TastyLoaderreads files eagerly, whereasClassfileLoaderdoes so lazily. The issue became visible with the new standard library compiled by Scala 3, which now generates Tasty files.By logging
Abstract.toByteArraycalls, I measured that we loaded 641 Tasty files (4.49 MB) to compile hello-world before this PR, whereas we now load only 100 Tasty files (0.80 MB) afterward.