-
Notifications
You must be signed in to change notification settings - Fork 9
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
Slow start of REPL when a pom file is present #187
Comments
Some details of interest:
|
I think I have some regrets about this code:
in PathConfig.java, rascal project, line 615 in Because while we are not reading from stdout, what is the guarantee that the process terminates and when? |
printing the |
I've just done some rough profiling, at least on windows, we also loose half of the time in the |
also, I think we might be looking at the slow start of maven. as the reported "total time" does not include time spend in starting maven:
so, 2s reported, but 5s actual. Similarly for the dependency get install of the plugin:
that takes 6.3s to complete. so on my machine, that's 11s for a single run of those two commands, and we are running them quite often. (before the REPL starts we also run it, since vscode asks for a project config) |
|
I've interesting results here: This is running
So you see the prompt returns within 2 seconds, but CPU time spent is almost 7 seconds. This is probably due to using multiple cores. If I run this with or without |
Aren't we just looking at the infamous cold starts of JVM processes? So starting maven takes time? I've snipped away one of the maven calls here: usethesource/rascal#1661 Also on my machine, counting with my hands, it takes longer than 2s. |
Solution directions:
|
Alternatives wanted! |
Could we try and encapsulate the maven-dependency-plugin specifically? So that we do not need all of maven to work, but just that plugin? |
I've tried that for the JUnit plugin. I can load all the objects but I can not populate all the injected data. The core platform is what reads the pom and then populates the data model that is injected to the parameters of all the plugins. It's well designed but its also a tight knot. |
@DavyLandman mentioned maven-embedder and way back when in 2018 this was not an option. But maybe now it is. It could also make other integrations with maven easy when we need them (for example for a component listing and installation UX in the repl). |
I've been stumbling through one issue after the other, but I think we're bitten by the dependency injection of maven. https://stackoverflow.com/questions/43264732/maven-embedded-3-3-9-is-it-possible Here a discussion is roughly saying: this won't work with shaded jars and other kinds of bundled jars. And that is what we are doing with rascal. |
okay, that pull request (usethesource/rascal#1661 ) contains the work to call maven inside of rascal, without starting a new jvm. on windows it reduces the call to build the path from 14s to less than 2s. @jurgenvinju: can you get it to work together with our maven shading, as it currently fails when it's inside of a big jar. |
I'll try :-) but not very soon. There's a backlog. |
So that windows users now whats happening until #187 gets resolved
Describe the bug
The REPL takes 40s+ to show up in the terminal view, and then another 40s+ to be available for the user.
To Reproduce
Here is a project config:
slow-vscode.zip
src/Hello.rsc
It takes 40s before any UI action is happening, so a user is confused that nothing is happening.
Then the terminal starts up and takes a long while before it's ready for use.
Expected behavior
Fast opening of the terminal, fast loading of the repl.
Stack traces
No errors in developer tools or rascal output window.
REPL window:
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: