IncrementalTextDocument.getText performance issue

IncrementalTextDocument.getText is much slower than FullTextDocument.getText

Unfortunately, there’s existing code that calls TextDocument.getText in loops. TextDocument.getText is the only API to get the content of a TextDocument and it was never specified that this is a potentially expensive operation.

The fix is probably to have IncrementalTextDocument.getText remember the string instead of recomputing it every time.

[dbaeumer]

@aeschli and I had a long disucssion about this. Our finding are:

• there is not a single best incremental text document implementation
• the implementation mostly depends on the scanner that is used afterwards. If the scanner for example uses a streaming API the text document best exposes something like a character sequence.

So we decided to move forward as follows:

• refactor the server code to make a TextDocuments generic so that users can bring their own text document implementation.
• remove the dependency to microsoft/vscode-textbuffer

Let server implementors decide which incremental text buffer implementation they want to use. One will be piece tree implementation.

Since we never had the incremental text document in a NON next version this will not be a breaking change.

[rebornix]

It sounds right to me. The way of reading text buffer can be only optimized based on what the scanner asks for and the detailed implementation of the buffer.

vscode-textbuffer can be used as an example how another text buffer implementation can be hooked into lsp-node in samples or readme.