> Some of the responses/notifications might be big e. g.
> 1. Diagnostics
> 2. Semantic highlight data(proportional to file size)

So, IIUC the scenario is that the LSP sends us large JSON data
structures, but we only ever use a fairly small portion of it, so
presumably a significant part of the total processing time is spent
gobbling data and parsing it into an internal data structure.

Beside limiting the total amount of time spent doing this (e.g. by
processing the data more efficiently (e.g. in C rather in Elisp) or in
parallel), the other issue is the fact that it shouldn't cause pauses in
the user interaction.  This can be obtained via true concurrency, or by
slicing the processing so it can be interleaved finely with user
interaction without any noticeable pauses.

Maybe an "easy" way to solve this particular problem is to define the
json parser as a "yield point".  This would even allow the
implementation of the json parser to spawn a separate thread and do the
parsing in a truly concurrent thread (tho the GC would need to be
extended to be able to deal with such truly concurrent non-Elisp
threads allocating Elisp data structures, maybe this can be done by
making those json threads use their own Elisp heap which gets joined
into the main heap at the end).

> a filter to that pipeline won't be a problem. One we (lsp-mode
> contributors) move it to native json I will resume the discussion if
> with some concrete testing data.

IIUC eglot does use the native json parser.  BTW, I'd be happy to hear
about the use of jsonrpc.el in lsp-mode (either failures or successes)
and more generally consolidation of effort between eglot and lsp-mode.


        Stefan