Investigate performance slowdown when editing server.xml

[TrevCraw]

Related to OpenLiberty/liberty-tools-intellij#687

We have observed performance slowdown with completion and hover both inside and outside of the featureManager section of the server.xml. There is a clear difference when moving from LT VS Code 23.0.6 to LT VS Code 23.0.9.

v23.0.6 contains LCLS 2.0 and v23.0.9 contains LCLS 2.0.1.

We have been able to consistently reproduce the slowdown on @mrglavas's Windows development machine as well as a Windows VM owned by @dessina-devasia and @aparnamichael.

This slowdown is observed in the latest releases of LT IntelliJ (24.0.3) and LT Eclipse (24.0.3) as well. The slowdown started in v24.0.3 for LT IntelliJ, and either v23.0.9 or v23.0.12 for LT Eclipse (some discrepancies in results between the two machines).

Attached is trace from the XML Support output in VS Code when invoking completion outside the featureManager section for the second time in server.xml with v23.0.6 and v.23.0.9. Both tests were with the same project and an existing target folder. The key line in the trace is line 34 showing v23.0.9 taking more than twice as long as v23.0.6.

23.0.6-VSCode-trace.txt
23.0.9-VSCode-trace.txt

Change set for LT VS Code 23.0.9 vs 23.0.6: 23.0.6...23.0.9. One change of note is #286, although this code path was not supposed to be used for 23.0.9. It was intended for supporting LCLS 2.1.

Change set for LCLS 2.0.1 vs 2.0: OpenLiberty/liberty-language-server@liberty-langserver-2.0...lemminx-liberty-2.0.1

[TrevCraw]

Next steps, as recommended by @gjdeval:

1. Can we get trace in the LCLS that would show receiving the request and generating the response, with preferably some steps along the way with timestamps?
2. We could check the LCLS Java heap health. We assume that GC logging is not enabled for LCLS, but it can be enabled by adding a JVM arg like this to the command used to start the Liberty LemMinX Language Server: -Xverbosegclog:.<dir>/verbosegc.%pid.%seq.log,5,20000 (replace <dir> with the target directory for logs). If we can get GC logs for 23.0.6 and 23.0.9 on a problem system (run the problem scenario say 25 times on each system), @gjdeval has offered to take a look at the logs.