[optimization] reuse compilation unit cache to compute symbols for document

[martinlippert]

The symbols for an open document are computed via the SpringSymbolIndex calling the computeSymbols method of the indexers in order to compute symbols from the content of the edited document instead of the content of the file on disc.

The SpringIndexerJava implements this using the same mechanism that is used for searching for symbols in files by creating its own ASTParser, and do the parsing - while the reconciling is doing the same on dirty documents in parallel, but using the CompilationUnitCache instead, which gets updated automatically on demand. To avoid the duplicated parsing logic, we should switch the SpringIndexerJava to use the CompilationUnitCache instead of doing its own parsing.

[BoykoAlex]

@martinlippert perhaps spring java indexer reconciling of sources opened in the editor should be skipped in favour of document reconcilers? Not sure how to proceed with the cached reconcile problems in this case though... maybe it is not a problem that some (a small subset) of reconcile problems isn't cached...

[martinlippert]

The overall caching of symbols and reconcile results happens only for document states that are stored to disc, so we should avoid adding anything to the cache that is based on dirty state of editors.

It looks to me like - at the moment - the computeSymbols that is executed when calculating symbols for an individual open document (the dirty state of an editor) is also executing a reconcile operation, even though another reconcile operation is already executed as a reaction to the didChangeDocument event from the reconcile engine itself.

So it looks like we have two different optimizations coming up here:

• the computeSymbols should use the compilation unit cache instead of creating its own parser environment to re-parse the comment
• the computeSymbols should not also execute a reconcile operation, because that is already done by the reconciling engine

Since the execution of the computeSymbols operation is triggered by the client whenever the client thinks it needs updated symbols, we can't have the reconciling for dirty editors inside of this computeSymbols operation. This should happen - as it does at the moment - as a reaction to the didChangeDocument event. And the document symbols should be computed only if the client asks for it. So the triggers seem to be the right ones, but the implementation should only execute exactly those features in an optimized way.

[martinlippert]

Fixed with 29f3974 and 31e3667