Skip to content
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

Investigate slow response times for completion for LCLS. #687

Open
mrglavas opened this issue Mar 13, 2024 · 8 comments
Open

Investigate slow response times for completion for LCLS. #687

mrglavas opened this issue Mar 13, 2024 · 8 comments
Labels
bug Something isn't working performance Responsiveness of the Liberty Tools plug-in that would be observably slow to a human user. should-fix SVT

Comments

@mrglavas
Copy link
Contributor

mrglavas commented Mar 13, 2024

While testing one of our recent drivers on my Windows 11 workstation, I'm noticing observably slow response times for completion requests in server.xml.

The user can see that something is loading, but I've observed it's taking up to 6 seconds just to display a list of feature names.

image

[Trace - 12:58:01] Received response 'textDocument/completion - (56)' in 5978ms.

@mrglavas mrglavas added the performance Responsiveness of the Liberty Tools plug-in that would be observably slow to a human user. label Mar 13, 2024
@turkeylurkey
Copy link
Member

turkeylurkey commented Mar 13, 2024

On Mac. The first time I do the above it takes 154ms. The second time it takes less, 72ms.
image

@mrglavas
Copy link
Contributor Author

mrglavas commented Mar 13, 2024

It is consistently slow for me. Doesn't get any faster the 2nd time I try. I wonder if there's some network call in the background to build that list, for example from a schema that isn't being cached and that could be arbitrarily slow depending on your environment. It's worth noting that similar slow performance has been observed during SVT testing: #689.

@turkeylurkey
Copy link
Member

Tested on Windows with lemminx 0.27.0, same issue.

@turkeylurkey
Copy link
Member

turkeylurkey commented Mar 19, 2024

On Windows. Editing pom.xml presumably the liberty extension is not used. Here the first completion takes 3.7s and the second takes 165ms. Generating elements inside the <project> element.
image
Generating the completion for this element took 35ms
image

@turkeylurkey
Copy link
Member

turkeylurkey commented Mar 19, 2024

On Windows. In bootstrap.properties generating this long list of options took 102ms
image
In server.env this shorter list took 24ms
image
image

@TrevCraw TrevCraw added bug Something isn't working SVT labels Mar 26, 2024
@TrevCraw TrevCraw self-assigned this Mar 26, 2024
@TrevCraw
Copy link
Contributor

TrevCraw commented Mar 26, 2024

Just wanting to note the information reported by @Jonathan-Maciel in this issue during SVT:

Liberty Tools Driver: 24.0.3-SNAPSHOT
Windows 11 VM with 16GB RAM
IntelliJ IDEA 2023.3.4 (Community Edition)
OpenJDK 18.0.2

Hovering a feature does not display the documentation: Screenshot 2024-03-12 at 11 17 56 AM

The response time is consistently over 2.5 seconds: Screenshot 2024-03-12 at 1 14 18 PM

The feature completion also takes over 10 seconds: Screenshot 2024-03-12 at 1 24 22 PM

@TrevCraw
Copy link
Contributor

TrevCraw commented Mar 26, 2024

Performance degradation while editing server.xml has also been observed in Liberty Tools for Eclipse (starting in 23.0.9 or 23.0.12 - still investigating) and Liberty Tools for VS Code (starting in version 23.0.9).

Issue open for LT VS Code: OpenLiberty/liberty-tools-vscode#329

@anusreelakshmi934
Copy link
Contributor

anusreelakshmi934 commented Sep 18, 2024

While running start in container i am experiencing slowness in loading server.xml feature tags.

Screen.Recording.2024-09-18.at.5.58.07.PM.mov

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working performance Responsiveness of the Liberty Tools plug-in that would be observably slow to a human user. should-fix SVT
Projects
Development

No branches or pull requests

4 participants