No need to run completion handler in async thread pool

[testforstephen]

Currently we use computeAsync and join the async result to handle completion and resolveCompletionItem requests synchronously. This is not quite efficient. A better implementation is to run them directly in the main dispatcher thread, which can ensure the completion is handled immediately and without waiting for another async scheduler.

[fbricon]

Can you measure the alleged performance improvement?

[testforstephen]

Can you measure the alleged performance improvement?

This PR improves the responsiveness of the completion feature by reducing thread contention. The performance benefit may vary depending on how busy the thread pool is.

Previously, the completion handler used computeAsync to spawn a new thread for completion task from a common thread pool, which was shared by many other requests (such as semantic highlighting, code actions, inlay hints, folding range, delegate commands, etc.). Meanwhile, the completion handler used result.join() to block the main jsonrpc thread. This resulted in two threads being occupied by a single completion task, which was wasteful of thread resources.

https://github.com/eclipse/eclipse.jdt.ls/blob/73ccd84d4a0f57312ece7c049c27c6e685a889fe/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/JDTLanguageServer.java#L592-L603

This PR changes the completion implementation to run completion task in main jsonrpc thread directly. This reduces the number of threads involved in each completion task from two to one, and also avoids competing with other requests for the common thread pool.

The performance benefit depends on how busy the thread pool is. If the pool is idle, the scheduling time for computeAsync is about 2 ms in my machine. But if the pool is busy, the scheduling time is unpredictable.

[jdneo]

test this please

[jdneo]

LGTM.

If it's on purpose to block the LSP request during completion. Then it's unnecessary to schedule it to the thread pool and join from the dispatch thread.

[testforstephen]

If it's on purpose to block the LSP request during completion. Then it's unnecessary to schedule it to the thread pool and join from the dispatch thread.

Yes, it's on purpose. This synchronous join behavior is from this PR #425.