Re: Running process filters in another thread

[yyoncho]

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 <address@hidden> 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