Re: Running process filters in another thread

[yyoncho]

Hi Stefan,

> E.g. why would the LSP servers send us

> megabytes of data?

Some of the responses/notifications might be big e. g.

1. Diagnostics

2. Semantic highlight data(proportional to file size)

and these combined with several concurrent LSP/DAP servers sending async

notifications. But as Eli mentioned I will have to prepare some test results and

also with emacs 27 native json support to see how it behaves. I have

started the discussion assuming that the reading of the process output is not

performed in the emacs UI thread but in OS thread and I was thinking that adding

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.

Thank you for your time.

Thanks,

Ivan

On Sat, Sep 29, 2018 at 9:11 PM Stefan Monnier <address@hidden> wrote:

>> It shouldn't be too hard to use a separate (OS-level) Emacs *process*
>> if you want to do the parsing without blocking the normal UI thread.
>> But it comes with other performance tradeoffs.
>
> Please correct me if I am wrong but I believe that I will still have
> to parse the input on UI thread but from a different
> format (e. g. using built-in print1/read) which in the end will have
> the same result.

The idea is that the other process would do the bulk of the "digestion"
so the amount of data it would send to the main Emacs (the "UI thread")
would hopefully be much smaller.

But I must admit not being sufficiently familiar with the details to be
able to discuss it seriously.  E.g. why would the LSP servers send us
megabytes of data?  Is it because it sends us back the whole file with
lots of detailed annotations everywhere (e.g. the kind of info we'd use
for font-lock-like purposes rather than for flymake-like purposes)?


        Stefan