GNU bug report logs - #79361
minor jsonrpc optimisation suggestions

Previous Next

To reply to this bug, email your comments to 79361 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Cc: João Távora <joaotavora <at> gmail.com>
Subject: minor jsonrpc optimisation suggestions
Date: Mon, 1 Sep 2025 20:58:50 +0200

[Message part 1 (text/plain, inline)]

Emacs's built-in JSON parser happily accepts encoded unibyte strings and buffers as input because JSON is specified at byte level. This means that any effort to decode the input to multibyte first is wasted. (This overhead is quite measurable in general.)

For jsonrpc this means that for good performance, make sure the process buffer is unibyte and set the process coding system to something like `binary`. The filter function will then be passed unibyte strings. (The `position-bytes` and `byte-to-position` calls become identity and can be eliminated.)

This should apply to both the old (libjansson) and new JSON parsers. The old json.el parser (json-read) doesn't cope well with unibyte input (unless it's all-ASCII, of course), so for the masochists you may want some compatibility code.

Here is a proof-of-concept patch, largely untested and untimed (well, it compiles and passes the tests).

[jsonrpc.diff (application/octet-stream, attachment)]

Message #8 received at 79361 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: joaotavora <at> gmail.com, 79361 <at> debbugs.gnu.org
Subject: Re: bug#79361: minor jsonrpc optimisation suggestions
Date: Tue, 02 Sep 2025 14:10:19 +0300

> Cc: João Távora <joaotavora <at> gmail.com>
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Mon, 1 Sep 2025 20:58:50 +0200
> 
> --- a/lisp/jsonrpc.el
> +++ b/lisp/jsonrpc.el
> @@ -548,11 +548,13 @@ initialize-instance
>      (set-process-buffer proc (get-buffer-create (format " *%s output*" name)))
>      (set-process-filter proc #'jsonrpc--process-filter)
>      (set-process-sentinel proc #'jsonrpc--process-sentinel)
> +    (set-process-coding-system proc 'binary 'binary)

Why not do this at make-process time?

>      (with-current-buffer (process-buffer proc)
>        (buffer-disable-undo)
>        (set-marker (process-mark proc) (point-min))
>        (let ((inhibit-read-only t))
>          (erase-buffer))
> +      (set-buffer-multibyte nil)

I would move this to make it the first thing we do in the buffer.

> +        ;; `json-read' requires decoded input.
> +        (json-read-from-string (decode-coding-string (buffer-string) 'utf-8)))))

Should be utf-8-unix, I believe, since JSON requires a literal \n as a
newline convention.

And yes, it would be nice to have timings.

Message #11 received at 79361 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: joaotavora <at> gmail.com, 79361 <at> debbugs.gnu.org
Subject: Re: bug#79361: minor jsonrpc optimisation suggestions
Date: Tue, 2 Sep 2025 21:32:21 +0200

2 sep. 2025 kl. 13.10 skrev Eli Zaretskii <eliz <at> gnu.org>:

> And yes, it would be nice to have timings.

These are obvious improvements at no cost, and JSON performance has turned out to be important for LSP and similar applications.

For what it's worth I've measured the difference that unibyte and binary coding make on synthetic cases (receiving JSON data and parsing it), not in eglot, but the improvement seems to be around 30-50 % which is much better than I expected.

Message #14 received at 79361 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Daniel Pettersson <daniel <at> dpettersson.net>,
 João Távora <joaotavora <at> gmail.com>, 79361 <at> debbugs.gnu.org
Subject: Re: bug#79361: minor jsonrpc optimisation suggestions
Date: Wed, 3 Sep 2025 15:04:28 +0200

On a more practical note, is there a dedicated maintainer for jsonrpc?
I lazily assumed it was João but now see Daniel Pettersson's name in MAINTAINERS (CC:ed).

If there isn't one, or (perhaps equivalently) the answer is the collective of interested Emacs devs with particular weight given to past jsonrpc contributors, then I'll just make a more polished patch, test some more, and push if there are no objections.

(For that matter, lsp-mode would benefit from a similar reform and more but I'll let someone else worry about that. Will be happy to answer questions though.)

Message #17 received at 79361 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: daniel <at> dpettersson.net, joaotavora <at> gmail.com, 79361 <at> debbugs.gnu.org
Subject: Re: bug#79361: minor jsonrpc optimisation suggestions
Date: Wed, 03 Sep 2025 16:38:58 +0300

> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Wed, 3 Sep 2025 15:04:28 +0200
> Cc: 79361 <at> debbugs.gnu.org,
>  João Távora <joaotavora <at> gmail.com>,
>  Daniel Pettersson <daniel <at> dpettersson.net>
> 
> On a more practical note, is there a dedicated maintainer for jsonrpc?
> I lazily assumed it was João but now see Daniel Pettersson's name in MAINTAINERS (CC:ed).
> 
> If there isn't one, or (perhaps equivalently) the answer is the collective of interested Emacs devs with particular weight given to past jsonrpc contributors, then I'll just make a more polished patch, test some more, and push if there are no objections.

Let's wait a bit more for João to chime in.

Message #20 received at 79361 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Daniel Pettersson <daniel <at> dpettersson.net>,
 79361 <at> debbugs.gnu.org
Subject: Re: bug#79361: minor jsonrpc optimisation suggestions
Date: Wed, 3 Sep 2025 15:33:04 +0100

[Message part 1 (text/plain, inline)]

On Wed, Sep 3, 2025, 14:04 Mattias Engdegård <mattias.engdegard <at> gmail.com>
wrote:

> On a more practical note, is there a dedicated maintainer for jsonrpc?
> I lazily assumed it was João but now see Daniel Pettersson's name in
> MAINTAINERS (CC:ed).
>

Yes, I've handed over maintainership a a while ago. Good call Cc'ing him.

>
> If there isn't one, or (perhaps equivalently) the answer is the collective
> of interested Emacs devs with particular weight given to past jsonrpc
> contributors, then I'll just make a more polished patch, test some more,
> and push if there are no objections.
>

Sounds like a plan.

João

[Message part 2 (text/html, inline)]

Message #23 received at 79361 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Daniel Pettersson <daniel <at> dpettersson.net>,
 79361 <at> debbugs.gnu.org
Subject: Re: bug#79361: minor jsonrpc optimisation suggestions
Date: Thu, 4 Sep 2025 19:29:01 +0200

[Message part 1 (text/plain, inline)]

Here is a proper patch. Tested with a few servers (clangd, ocaml-lsp-server), and everything seems to work including Unicode in identifiers and doc strings.

[0001-Avoid-unnecessary-text-decoding-in-jsonrpc-for-speed.patch (application/octet-stream, attachment)]

Message #26 received at 79361 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Pettersson <daniel <at> dpettersson.net>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 João Távora <joaotavora <at> gmail.com>, 79361 <at> debbugs.gnu.org
Subject: Re: bug#79361: minor jsonrpc optimisation suggestions
Date: Thu, 04 Sep 2025 22:49:06 +0200

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> Here is a proper patch. Tested with a few servers (clangd,
> ocaml-lsp-server), and everything seems to work including Unicode in
> identifiers and doc strings.

Tested with eglot and dape. It feels snappier and unicodes are still
live.  This is great!

Daniel

Message #29 received at 79361 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: daniel <at> dpettersson.net, joaotavora <at> gmail.com, 79361 <at> debbugs.gnu.org
Subject: Re: bug#79361: minor jsonrpc optimisation suggestions
Date: Fri, 05 Sep 2025 09:39:02 +0300

> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Thu, 4 Sep 2025 19:29:01 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>  79361 <at> debbugs.gnu.org,
>  Daniel Pettersson <daniel <at> dpettersson.net>
> 
> Here is a proper patch. Tested with a few servers (clangd, ocaml-lsp-server), and everything seems to work including Unicode in identifiers and doc strings.

Thanks.

Can this change affect programs using jsonrpc in any way?  For
example, do we have hooks or user-defined functions that can be called
with this buffer the current buffer?  If so, this change should be
called out in NEWS, because now the buffer is unibyte and the text in
it is undecoded.

Message #32 received at 79361 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: daniel <at> dpettersson.net, joaotavora <at> gmail.com, 79361 <at> debbugs.gnu.org
Subject: Re: bug#79361: minor jsonrpc optimisation suggestions
Date: Fri, 5 Sep 2025 10:45:42 +0200

5 sep. 2025 kl. 08.39 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Can this change affect programs using jsonrpc in any way?  For
> example, do we have hooks or user-defined functions that can be called
> with this buffer the current buffer?

I don't think so, because jsonrpc creates that buffer itself and treats it entirely as its own property. Its name starts with a space, making it internal. There should be no user-visible changes.

Message #35 received at 79361 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 daniel <at> dpettersson.net
Cc: joaotavora <at> gmail.com, 79361 <at> debbugs.gnu.org
Subject: Re: bug#79361: minor jsonrpc optimisation suggestions
Date: Fri, 05 Sep 2025 13:48:39 +0300

> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Fri, 5 Sep 2025 10:45:42 +0200
> Cc: joaotavora <at> gmail.com,
>  79361 <at> debbugs.gnu.org,
>  daniel <at> dpettersson.net
> 
> 5 sep. 2025 kl. 08.39 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> > Can this change affect programs using jsonrpc in any way?  For
> > example, do we have hooks or user-defined functions that can be called
> > with this buffer the current buffer?
> 
> I don't think so, because jsonrpc creates that buffer itself and treats it entirely as its own property. Its name starts with a space, making it internal. There should be no user-visible changes.

What about jsonrpc-event-hook?  It runs in the buffer returned by
jsonrpc-events-buffer -- is that affected by these changes?

Message #38 received at 79361 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79361 <at> debbugs.gnu.org, daniel <at> dpettersson.net, joaotavora <at> gmail.com
Subject: Re: bug#79361: minor jsonrpc optimisation suggestions
Date: Fri, 5 Sep 2025 17:16:20 +0200

[Message part 1 (text/plain, inline)]

5 sep. 2025 kl. 12.48 skrev Eli Zaretskii <eliz <at> gnu.org>:

> What about jsonrpc-event-hook?  It runs in the buffer returned by
> jsonrpc-events-buffer -- is that affected by these changes?

No, that buffer is not affected. It's a pure text buffer, used as a debug log.

However, this made me look at that events buffer. It does seem that eglot and/or jsonrpc logs way too much. It seems unlikely that this wouldn't affect performance. Although the user can turn off much of it (setting :size in `eglot-events-buffer-config` to 0), this should probably be the default.

In fact, the way eglot keeps the events buffer below its maximum size isn't wonderful either:

1076             (save-excursion
1077               (goto-char (point-min))
1078               (while (> (buffer-size) max)
1079                 (delete-region (point) (progn (forward-line 1)
1080                                               (forward-sexp 1)
1081                                               (forward-line 2)
1082                                               (point)))))))))))

So it deletes a small chunk at the very beginning of the buffer. Surely that will ping-pong the gap between the beginning and the end of the buffer every couple of logged items, ie a memmove of all the contents each time? We could do better here.

What about changing this to chopping off a constant proportion of the buffer instead, say 1/3? At least that gives an amortised cost that is independent of the buffer size. It doesn't help with the occasional latency spike though, so again, the default events buffer :size should probably be 0; formatting log items is also costly. Proposed patch attached.

However, even with the :size set to 0, we still get forwarded messages from the stderr buffer in the events buffer, and some language servers seem to be quite chatty. These log entries do not honour the max buffer size at all, which is probably a bug. I didn't do anything about that.

[0001-Less-expensive-jsonrpc-and-eglot-logging-bug-79361.patch (application/octet-stream, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.