Re: Running process filters in another thread

[yyoncho <yyoncho@gmail.com>]

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

Hi Stefan,

> Could you point to concrete
> examples, bug reports, and things like that?

There are several discussions in reddit/github related to lsp-mode being
slow
due to json parsing and the usual answer is that things are going to be
better
after switching to native json parsing available in Emacs 27 and the
following
issue is referenced: https://github.com/emacs-lsp/lsp-mode/issues/210 but I
believe that this is not going to happen to have the following points in
mind:

1. You could have multiple running LSP servers and each of them could post
big(1m+)
updates at any time.

2. A similar problem exists for Debug Adapter Protocol client dap-mode
(https://github.com/yyoncho/dap-mode) where you could have as much debug
sessions as you want and each of them could send an update at any time too.

My point is that Emacs should be able to process a lot of json
requests/responses
and still being responsive and if this requires parsing some text format
messages(e. g. Json/XML/emacs built-in) on UI thread this is not going to
happen.

> 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.

Thanks,
Ivan

On Sat, Sep 29, 2018 at 2:04 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > I want to raise this topic regarding the rise of Language servers and
> > the performance problems that are related to parsing process output on
> > UI thread.
>
> I'm not necessarily surprised that there are performance problems there,
> but I'm not actually familiar with them.  Could you point to concrete
> examples, bug reports, and things like that?
>
> Ideally, has someone investigated to see exactly where/when the
> performance problems show up?
>
> > I am not familiar with Emacs internals and I am not sure whether this
> > is doable but I wonder whether providing the option to do the
> > parsing(and probably more?)  in a separate thread and then call the
> > *filter* function on emacs side in UI thread with elisp data
> > structures like lists, hashmaps etc. instead of raw string is feasible
> > which would be similar to what is happening in Javascript world.
>
> 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.
>
>
>         Stefan
>
>
>

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