GNU bug report logs - #78773
[PATCH] Speedup url-retrieve-synchronously for low-latency connections

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 78773 <at> debbugs.gnu.org, larsi <at> gnus.org, steven <at> stebalien.com
Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for
 low-latency connections
Date: Thu, 12 Jun 2025 14:10:23 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Steven Allen <steven <at> stebalien.com>,  78773 <at> debbugs.gnu.org,
>   larsi <at> gnus.org
> Date: Thu, 12 Jun 2025 10:41:41 +0200
> 
> >>>>> On Thu, 12 Jun 2025 09:45:17 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     Eli> What happens if you leave the 1st argument of accept-process-output at
>     Eli> its current nil value, but change the 2nd argument to be 0.005 instead
>     Eli> of 0.05 (i.e., 10 times smaller)?
> 
> That speeds it up, although not as dramatically
> 
>     Eli> Also, how many other sub-processes (of any kind, not just network
>     Eli> processes) do you have in that session when you are testing this
>     Eli> issue?
> 
> The answer to that is important, since there are a couple of loops in
> `wait_reading_process_output' that depend on that, and can trigger DNS
> or TLS operations as a result. But Iʼve just tested this in 'emacs -Q'
> with zero processes, and I see the speedup.

If this happens with a single sub-process, it's strange.  It means
that we somehow wait for the full timeout even though some output from
the single sub-process arrives, which should have ended the wait.  Or
what am I missing?

>     Eli> Unfortunately, I doubt that we will get any useful answers to this
>     Eli> question.  We need to understand better why asking for output from a
>     Eli> single process has such a dramatic effect in your case with localhost
>     Eli> requests.  If it happens only with localhost requests, perhaps we
>     Eli> could make some changes only for that case.
> 
>     Eli> Robert, any ideas or suggestions?
> 
> The fact that itʼs localhost shouldnʼt matter. The code in question is
> convoluted, as you well know, so figuring out whatʼs going on needs us
> to have a good understanding of which cases trigger this
> behaviour. But the evidence so far points at the handling of the
> timeout.

In the case of a remote host, the speedup was marginal, so I think
the localhost does matter, somehow.

Perhaps instrumenting wait_reading_process_output with printf's would
help to understand the control flow in the case of nil and non-nil
PROCESS argument?

Previous Next

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