Re: Running process filters in another thread

[yyoncho <yyoncho@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

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 <monnier@iro.umontreal.ca>
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
>
>
>

[-- Attachment #2: Type: text/html, Size: 2664 bytes --]