Debounce code lens request based on average duration

[jdneo]

Currently, the VS Code used the adaptive debouncing in the outline view and we found that this is very useful strategy to improve the performance. For example, we tried this in our Code Lens provider and it do help a lot for the performance.

So is it possible to provide an API or in whatever form to expose it and let the extension writer be able to use it?

[jrieken]

Do you have some more details for me? Most language features use the provider pattern, like DocumentSymbolProvider or CodeLensProvider, which means extension shouldn't be concerned with debouncing because part of the contract is that VS Code decides when to ask a provider for data.

Can you elaborate how you have used that in your Code Lens provider?

[jdneo]

Sure, for example, in Java Test Runner, if the user is editing a very large test source file, usually it will take a while to resolve the the code lenses (send a request to Language Server and wait for the response). We found the adaptive debounce is very useful because:

• When the user is keep editing, the adaptive debounce can simply eliminate those cancelled request by checking the cancellation token.
• Since the debounce time is adaptive and calculated by its historical execution time, so it will be more suitable, and the language server can have more time to do those important tasks(like completion), before the debounced request goes in.

[jrieken]

Hm, wouldn't it be better if VS Code also uses the debouncing for code lens requests? With that every extension would benefit from it without adopting anything

[jdneo]

Yes I think enabling adaptive debounce in code lens requests is exactly what we want to have.

So... will it be an optional setting when register the code lens provider or it will just enabled inside vs code without exposing anything?

[jrieken]

Yeah, I'd say we will just enable it - just like we did it for outline. Today, code lens statically debounces at 250ms and we can use the same mechanism we use for outline, e.g keep a moving average per file and debounce by that (without lower/upper bounds)