GNU bug report logs - #69241
[PATCH] Jsonrpc: improve performance of process filter function

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Daniel Pettersson <daniel <at> dpettersson.net>
Cc: 69241 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#69241: Fixed patch issues
Date: Sun, 10 Mar 2024 14:41:07 +0000

On Sun, Mar 10, 2024 at 2:28 PM Daniel Pettersson
<daniel <at> dpettersson.net> wrote:

> As I have previously stated I am willing to take on the maintainer role
> for Jsonrpc.

Thank you Daniel.  It'll be in very good hands.

> > +           ;; `timer-activate' orders timers by time, which is an
> > +           ;; very expensive operation when jsonrpc-mqueue is large,
> > +           ;; therefore the time object is reused for each timer
> > +           ;; created.
>
> I am interested in what both of you think about relying on undocumented
> behavior.
>
> To grasp the scope of this issue, an adapter server sent 50 000
> messages. With `read-process-output-max' set to the platforms max, each
> of those messages where placed on `timer-list' in the same call to
> jsonrpc's filter function, which then had to be sorted as O(N^2)
> (calls to timer--time-less-p).
>
> Which makes Jsonrpc unusable for that particular server.

I think your analysis is sound, Daniel. As you have noticed the run-at-time 0
is not to actually  use a timer, but just to get a call that is independent
from the current  call stack which may be nested because of the use case
of bug#67945.

The calls must be processed in the order of the queue though, but in
theory that shouldn't lead to O(N^2) if a suitable technique is found (perhaps
different from (run-at-time 0)).

Finally 50.000 is a gigantic amount -- are all of these essential?  Can't the
server coalesce this data into fewer messages within the DAP protocol?

João

Previous Next

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