-
Notifications
You must be signed in to change notification settings - Fork 323
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 openFile
request may disrupt initial loading of a project
#11721
Comments
Trying to optimize startup a bit where Akka has a big share of the pie and stumbled upon akka/akka#25569. TL; DR |
Hubert Plociniczak reports a new STANDUP for the provided date (2024-12-02): Progress: (Previously reported under incorrect ticket number) Investigating slow startup on cloud and how to remedy it. Tinkering with building a native image for language server. Started looking into #11734, can reproduce, sometimes. Planning tickets. It should be finished by 2024-12-05. Next Day: Next day I will be working on the #11721 task. Continue investigating the issue. |
Hubert Plociniczak reports a new STANDUP for yesterday (2024-12-03): Progress: Bisecting for #11734, found culrpit, reassigned. Managed to build native image of LS as a way to remedy slow startup. Needs more testing. Playing with AoC. It should be finished by 2024-12-05. Next Day: Next day I will be working on the #11721 task. Continue investigating the issue. |
Hubert Plociniczak reports a new STANDUP for the provided date (2024-12-09): Progress: Continued investigating native-image build issues. It seems like instrumentation is done twice - once without message transport set and once with, causing setup issues. It should be finished by 2024-12-13. Next Day: Next day I will be working on the #11721 task. Continue investigating the issue. |
Hubert Plociniczak reports a new STANDUP for the provided date (2024-12-10): Progress: Continued investigating native-image issues. Looks like Graal is doing some pre-initialization for Context so that on the first usage in runtime instrumentation message transport is null. Successive attempts at initialization work. Needs more debugging. It should be finished by 2024-12-13. Next Day: Next day I will be working on the #11721 task. Continue investigating the issue. |
Hubert Plociniczak reports a new STANDUP for yesterday (2024-12-11): Progress: Looks like I figured out blocker for LS native image - shared engine was causing issues in AOT when simultaneously setting up message transport for runtime instrumentation. Also resolved logging problems - missing entries in native image configuration that were impossible to debug due to silently dropped exceptions deep within the proprietary logging implementation. It should be finished by 2024-12-13. Next Day: Next day I will be working on the #11721 task. Continue investigating the issue. |
Hubert Plociniczak reports a new STANDUP for the provided date (2024-12-11): Progress: More tweaks to native-image configuration. Got normal projects to boot without issues. Verified record button ticket, can't reproduce. Need to clean up and prepare PR. It should be finished by 2024-12-13. Next Day: Next day I will be working on the #11721 task. Continue investigating the issue. |
Hubert Plociniczak reports a new STANDUP for the provided date (2024-12-13): Progress: More testing to native image build. Dealing with finding the right executable. Still not in a releasable state. It should be finished by 2024-12-13. Next Day: Next day I will be working on the #11721 task. Continue investigating the issue. |
Hubert Plociniczak reports a new STANDUP for the provided date (2024-12-16): Progress: Draft PR created. Needed more testing as some configuration got stale. It should be finished by 2024-12-16. Next Day: Next day I will be working on the #11882 task. Take a break from native image and pick urgent tickets |
Users reported no/very slow loading of some suggestions. The issue is particularly on slow/underpowered machines.
While lack of suggestions is the end result, the problem appears in ydoc not dealing well with receiving answers to its request well beyond its hardcoded limit (15secs).
This is not a new issue, and mitigation has been added to backend/LS as well as GUI. It appears that the mitigation has not been sufficient/loading times have deteriorated.
The text was updated successfully, but these errors were encountered: