[critical] Slow code completion takes more than a 1 sec.

[gayanper]

When invoking LSP code completion the spring-boot completion take more than 1 sec.

[gayanper]

snapshot-1558515981259-sampling-completion.zip

[gayanper]

@martinlippert @BoykoAlex This particular work-space i'm working with has nearly 10K files. Seems like there is a AST parsing happening on each completion call. This happens mainly when working in java files, i haven't checked the config files.

[gayanper]

This happens in latest nightly

[BoykoAlex]

@gayanper do you happen to have that workspace publicly available in a git repo somewhere? I see that resolving/compiling a CU takes time. Maybe we cannot do much about it for a large workspace. However, any subsequent CA invocation in the same file should quick because the resolved CU is cached... Are you seeing the same time for CA in the same file on subsequent invocations?

[gayanper]

@BoykoAlex The workspace is a private workspace which has proprietary code. Well the problem is subsequent invocations at the same place in the same file seems have constant delay :(.

[kdvolder]

subsequent CA invocation in the same file should quick because the resolved CU is cached

Well... I assume the user will not just invoke CA twice in a row without actually typing at least a little in between, so some changes will usually happen to the file content before the next CA invocation. So wouldn't that invalidate the cache? Parsing current file is sort of unavoidable is it not?

[BoykoAlex]

Yes... we should probably somehow have a working copy on the LS side and update it probably with every doc content change message for things to be as quick as in JDT...

[spring-projects-issues]

(comment in Pivotal Tracker added by Alex Boyko:)

@mlippert I think we should do this post 4.2.2... CU parsing on Win takes ~500ms and is the bottleneck. I have some ideas how to update CU cache for doc open/changed/closed. It seems to help when i did it for doc change. It won't be a one day work and there will some risk with those changes too. It doesn't look like regression to me...

[spring-projects-issues]

(comment in Pivotal Tracker added by Alex Boyko:)

CU parsing in JDT calls java.io.File#isDirectory() many times when resolves types and this where majority of time goes

[spring-projects-issues]

(comment in Pivotal Tracker added by Alex Boyko:)

Polished prototype is in sts4 git repo branch: ast-parser

[mlippert]

I think you meant @martinlippert not me.

[spring-projects-issues]

(comment in Pivotal Tracker added by Martin Lippert:)

I tried the branch and using content-assist in the java editor a lot and it was always super fast and responsive. I think this is a great step forward.

The reflection work is not pretty, but since we don't have to make this work for various Eclipse versions at the same time, I am not so worried about it.

Do you have automated unit tests to discover problems with the reflection hacks if we decide to update the jdt.core version inside of the language server?

[spring-projects-issues]

(comment in Pivotal Tracker added by Alex Boyko:)

Pushed to master (test is there)
@gayanper Can you please give this build a try on Win: https://download.springsource.com/snapshot/STS4/nightly/dist/e4.12/spring-tool-suite-4-4.3.0.CI-B1878-e4.12.0-win32.win32.x86_64.zip
CA seems to be about as fast as on mac there for me