GNU bug report logs -
#69241
[PATCH] Jsonrpc: improve performance of process filter function
Previous Next
Full log
Message #23 received at 69241 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 1 year and 72 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.