Performance bottleneck in Ui Thread

[jukzi]

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

callstack:

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]

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

[jukzi]

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

[jukzi]

[mickaelistria]

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]

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]

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.