Performance issue on large project

[snjeza]

Fixes #1469

Signed-off-by: Snjezana Peco [email protected]

[fbricon]

Can you please give some details about this change? Why? How? How much improvement is expected?

[snjeza]

Can you please give some details about this change? Why? How? How much improvement is expected?

Java LS locks whole workspace when opening, closing changing, validating a file.
The PR locks only used file(s).
We also avoid the workspace update when handling the open/close/change operations.

[fbricon]

I tried loading the guava project with and without this fix, but wasn't able to spot any significant difference when invoking completion (as per #1469 (comment)).
The changes look pretty sane to me, but I'd really love to see a scenario which shows a positive impact of this change. @testforstephen @jdneo @Eskibear can you give it a try?

[snjeza]

Additional features:

• stop hover, codeAction and findLinks when it is cancelled.
• don't reconcile a compilation unit within BaseDocumentLifeCycleHandler.performValidation(IProgressMonitor). It is reconciled later within publishDiagnostics(IProgressMonitor) - 2da94de#diff-49d07c54e1e695e6884afffabd2b7fafR181

[testforstephen]

I tried the fix on spring-boot project (5k+ files, 100+ gradle projects), i also didn't observe an obvious improvement. It's still a little lagging on completion, especially becomes more bad when opening a larger file (e.g. 2k+ LOC). Seems worthwhile to try lazy resolving addtionalTextEdits.

@Eskibear has more experience on completion performance analysis, could you have a look at the fix?

[Eskibear]

I just tried guava which contains 20K+ java files, on my mac with 2.9G Dual-Core i5 + 8G RAM. No suspicious extension enabled.

Either with or without this PR, I don't see significant performance issue. Editing CharMatcher.java metioned by the issue owner, time cost for textDocument/completion was 500ms ~ 1500ms in both cases, obviously lagging but somehow usable for me.

Then I broke down the time cost in jProfiler, finding unit.codeComplete and getCompletionItems are costing most time, and the ratio is about 1:3, meaning that calculating textEdits for import statements is a big rock.

It's as expected and matches our previous investigation. And for the moment, I think that lazy resolving addtionalTextEdit should be a promising way to improve the performance.

[snjeza]

Either with or without this PR, I don't see significant performance issue. Editing CharMatcher.java metioned by the issue owner, time cost for textDocument/completion was 500ms ~ 1500ms in both cases, obviously lagging but somehow usable for me.

The PR doesn't change textDocument/completion than codeAction, triggerValidation, hover, findLinks... The PR should enhance overall VS Code performance.

[fbricon]

Thanks @snjeza!