search

eclipse / lsp4e

Language Server Protocol support in Eclipse IDE
Eclipse Public License 2.0
65 stars 54 forks source link

Performance bottleneck in Ui Thread #907

Open jukzi opened 8 months ago

jukzi commented 8 months ago

during sampling full build of eclipse platform workspace i saw this: image callstack: image image

at best UI thread would not perform I/O at all, but at east it should not call super slow java.io.File.getCanonicalPath ()

jukzi commented 8 months ago

org.eclipse.lsp4e.LSPEclipseUtils.findResourceFor () org.eclipse.lsp4e.outline.SymbolsLabelProvider.getImage () <- maybe cache that image? org.eclipse.lsp4e.outline.CNFOutlinePage.labelProviderChanged ()

jukzi commented 8 months ago

eclipse.buildId=4.31.0.I20240204-1800 java.version=21.0.2 win10

jukzi commented 8 months ago

image

mickaelistria commented 8 months ago

findResourceFor is a basic workspace query, that doesn't deal with IO, so I've retitled the issue. Moreover, this particular method cannot be optimized as about all of its execution time is spent in Workspace.findFilesForLocationURI. This stack most likely come from refreshing the Outline view; the resource is necessary in order to compute markers for the given symbol. However, the findResourceFor operation can probably be cached somehow in the label provider: IIRC, it's a stateful class that lives as long as LSP4E provides an outline, so caching the URI->resolution result in it might work and save most calls to findResourceFor.

jcompagner commented 8 months ago

i have the same thing, i just need to have the outline view closed because with it it is very hard to work inside editors..

ghentschke commented 7 months ago

The next step would be to refactor the org.eclipse.lsp4e.outline.LSSymbolsContentProvider to support partial results as described here and use something like org.eclipse.jface.databinding.viewers.ObservableListTreeContentProvider<E> to support lazy loading.