Re: Running process filters in another thread

[yyoncho <yyoncho@gmail.com>]

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

Hi Stefan,

> If we really use all of the data, then I can't see how processing the
> bytes and parsing them can be the dominating factor,

There are a lot of requests that are handled by updating some map(e. g.
received diagnostics
for buffer X) and the data is not used right away and the parsing is the
dominating factor.
This makes me think that we can span subprocess and use it as a store. I
will have to do some
benchmarking of communication between emacs and subprocess.

> No, you could have the subprocess send a parsed JSON object, I think.
@eliz@gnu.org <eliz@gnu.org> can you elaborate on that are you referring to
what emacs-async
(https://github.com/jwiegley/emacs-async) is doing?

Thanks,
Ivan

On Sun, Sep 30, 2018 at 4:01 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >> 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.
> >
> > AFAIK this is not the case, LSP is pretty minimal. This could be true
> > for some limited cases but in general we need all of the data.
>
> If we really use all of the data, then I can't see how processing the
> bytes and parsing them can be the dominating factor, so
> a `start-json-process` wouldn't make any significant difference.
>
> But at least in your example of semantic highlight we definitely don't
> have to use all of the data, but only the portion relevant for the
> currently displayed parts of the buffer.
>
>
>         Stefan
>

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