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

Previous Next

Full log

View this message in rfc822 format

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

(I dropped dick chiang from the CCʼs)

>>>>> 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.


    >> **Historical context**
    >> 
    >> `url-retrieve-synchronously' was changed to wait on "nil" in:
    >> 
    >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49897,
    >> 
    >> Motivated by this bug report:
    >> 
    >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49861
    >> 
    >> However, the patch in question also changed the rest of
    >> `url-retrieve-synchronously' so I'm hoping the issue lies elsewhere?

    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.

Robert
-- 

Previous Next

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