search

redhat-developer / vscode-java

Java Language Support for Visual Studio Code
Eclipse Public License 2.0
2.08k stars 442 forks source link

After waiting for one night, it takes about 1 minute to hover on the class for the first time #2108

Closed mozhuanzuojing closed 3 years ago

mozhuanzuojing commented 3 years ago

When I work every morning, I open a java file for the first time, place the mouse on a certain class, and wait for about 1 minutes before there is feedback. I used jProfiler to record the CPU activity graph of jdt.ls, help to see if it is the problem? I'm not sure if this is an issue.

Environment
Steps To Reproduce
  1. Open a project and wait for one night
  2. Make sure to open a java file for the first time, place the mouse on a class, and wait for hover feedback

image

Current Result

need wait about 1 minutes ，then receive feedback

Expected Result

hover，waiting time does not exceed 10 seconds

image

Additional Informations

I am also preparing to test the situation of different projects, which will be written here later.

rgrunber commented 3 years ago

Is there any indication that the project is being loaded/built when you do this ? The javadoc hover is dependent on the project build completing, so generally when one tries to hover over some type while that happens you would probably see some smaller "loading" popup until the project has finished loading.

However, if the project is already loaded, with the VSCode editor simply staying open the whole time, and you still see the loading, that could be an issue. It's strange because we do have code to abort loading beyond 500ms ( https://github.com/eclipse/eclipse.jdt.ls/issues/1664 ), and just display a much simpler hover.

mozhuanzuojing commented 3 years ago

Is there any indication that the project is being loaded/built when you do this ? The javadoc hover is dependent on the project build completing, so generally when one tries to hover over some type while that happens you would probably see some smaller "loading" popup until the project has finished loading.

However, if the project is already loaded, with the VSCode editor simply staying open the whole time, and you still see the loading, that could be an issue. It's strange because we do have code to abort loading beyond 500ms ( eclipse/eclipse.jdt.ls#1664 ), and just display a much simpler hover.

@rgrunber the project is already loaded, with the VSCode editor simply staying open the whole time, there is no compiling and building. If it is a particularly small project, there are only a few java files. There will be no waiting. I also found that as long as my mouse pointer is placed in VSCode, no matter whether the java file is opened or not. Will trigger org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.didChangeWatchedFiles

this is a hover normal CPU Call Tree

hover normal CPU Call Tree

hover waiting a minute CPU Call Tree.html.zip

mozhuanzuojing commented 3 years ago

I also often encounter loading during the development process, and the workspace is not compiled. What I can see with Jprofiler is 29.6%-69,487 ms org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.didChangeWatchedFiles. I will test with springboot later.

image

mozhuanzuojing commented 3 years ago

@rgrunber I tested the spring-boot project and had the same problem. the first hover until jdt.ls return information, which lasted 3 minutes.

git clone -b 2.5.x https://github.com/spring-projects/spring-boot.git

my settings.json and gradle.properties

snjeza commented 3 years ago

@mozhuanzuojing

Could you try update the following gradle properties

org.gradle.vfs.watch=true

to

org.gradle.vfs.watch=false
mozhuanzuojing commented 3 years ago

2081 same

mozhuanzuojing commented 3 years ago

@mozhuanzuojing

Could you try update the following gradle properties

org.gradle.vfs.watch=true

to

org.gradle.vfs.watch=false

@snjeza @rgrunber it's ok, Thank you all! Hope this configuration can be introduced to the top.

This great change saves an average of more than an hour per day!

Finally confident to continue to study the gradle plugin.

snjeza commented 3 years ago

Related issue - https://github.com/eclipse/eclipse.jdt.ls/pull/1876#issuecomment-920295715

rgrunber commented 3 years ago

I think it's worth adding an entry to our https://github.com/redhat-developer/vscode-java/wiki/Troubleshooting .

rgrunber commented 3 years ago

I've added https://github.com/redhat-developer/vscode-java/wiki/Gradle-Support#performance-degrades-with-gradle-project for now. @snjeza Is the reasoning just performance degredation due to limited resources to support the Gradle VFS over long periods of time or is it something else ?