From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: yyoncho Newsgroups: gmane.emacs.devel Subject: Re: Running process filters in another thread Date: Sat, 29 Sep 2018 10:35:19 +0300 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d9829c0576fd9d79" X-Trace: blaine.gmane.org 1538206449 27501 195.159.176.226 (29 Sep 2018 07:34:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Sep 2018 07:34:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: monnier@iro.umontreal.ca Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 29 09:34:05 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g69lM-00071Z-QG for ged-emacs-devel@m.gmane.org; Sat, 29 Sep 2018 09:34:05 +0200 Original-Received: from localhost ([::1]:49828 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g69nT-0004OD-2l for ged-emacs-devel@m.gmane.org; Sat, 29 Sep 2018 03:36:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g69mm-0004O7-TU for emacs-devel@gnu.org; Sat, 29 Sep 2018 03:35:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g69ml-0001va-Ma for emacs-devel@gnu.org; Sat, 29 Sep 2018 03:35:32 -0400 Original-Received: from mail-oi1-x230.google.com ([2607:f8b0:4864:20::230]:38205) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g69ml-0001vM-Fu for emacs-devel@gnu.org; Sat, 29 Sep 2018 03:35:31 -0400 Original-Received: by mail-oi1-x230.google.com with SMTP id u197-v6so7337149oif.5 for ; Sat, 29 Sep 2018 00:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=af0EdkZo5MRwr9DZ4pUSwQURCAOphX6IInX4NjwJ6tc=; b=gWu0QJRKd3y3O5DhjyLFZf/HrM+A2Bx3M2uHvwoJoyEcW67Y9CGOwOhioASHbNqG52 cxqo0FwI9oSQuHyfLZiAIwJjG46HzVjBUk5JSWwrDHajAZoYBp+6K7LaXdmjqDkM7hgW smRKv7Xy5NxORTTIoCOrQGEBz4XwMidowuwvHFY8lM9u5qax4Fh5wH4oNLL2GmeSPR5q IAVKZAsHtxrN2w2SZqPjX0emLdXfPGxZzScOYyhVvGtUUW4QPEiPquuCTTiO3rHccz7+ m7Whsyv9TQIk1uB36Ynengj/8ulDzbnXtCrd7pwaNya3os6DZxO6MC/9YCh50lGRJ3Ov TGzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=af0EdkZo5MRwr9DZ4pUSwQURCAOphX6IInX4NjwJ6tc=; b=HSKaMtPh6p2Dr1LPOYKKqnscqQNYQHbxFPjxhFTyzaJgYzApw8IPAC513jZuofqrK0 blXtIOEqysGJ0tSBpMa5Lp2txin2FYeMIuvj7ICP9q369ymrPAptP+Vsh3ZGMtGeJYm+ Zs37GVit9cyb/08vDVQMFQo8+Lxf5KIDiQZaj96AalVUcm53xGaZKEcCSHGcHqRD6JOO 6sBsiDmA6WThVG8F6YCzIFVBjSdPxKioiVqcrOWx+2EM5IHi36SHAA4f4cmhsVbf6JED q5NsSZ0PObiNGwWvC0e7n3ua4hAJf0b7nrkx8RvK5Lgnwqt3/HsIxDPz+kn9E1OIHLVt KTlw== X-Gm-Message-State: ABuFfojegN0gm0G2N7cS7QIvk5S1x5dhMSOmkbIvo0o5PGZFE6D/aznF 1+ipVZv+3URyVMyZU31kJCpZWny1WcAzltdGUuY= X-Google-Smtp-Source: ACcGV60eOWww/afgIOD+oapQ+9kGeuCC/HGUvWwUDtItfh/cab1O+/CjyYjCi3Rtqi+B9PKOB5+65s7Rp93wyzARNTk= X-Received: by 2002:aca:508f:: with SMTP id e137-v6mr962975oib.73.1538206530632; Sat, 29 Sep 2018 00:35:30 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:230128 Archived-At: --000000000000d9829c0576fd9d79 Content-Type: text/plain; charset="UTF-8" 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 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 > > > --000000000000d9829c0576fd9d79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stefan,

> Could you point to concrete
> examp= les, 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
believe that this is not going to happen to= have the following points in mind:

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

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

My poin= t is that Emacs should be able to process a lot of json requests/responses<= /div>
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*
&= gt; if you want to do the parsing without blocking the normal UI thread.
> But it comes with other performance tradeoffs.

<= /div>
Please correct me if I am wrong but I believe that I will still h= ave 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 s= ame 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 regard= ing 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.=C2=A0 Could you point to concr= ete
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<= br> > is doable but I wonder whether providing the option to do the
> parsing(and probably more?)=C2=A0 in a separate thread and then call t= he
> *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.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan


--000000000000d9829c0576fd9d79--