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: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>
Cc: 78773 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: bug#78773: [PATCH] Speedup url-retrieve-synchronously for low-latency connections
Date: Thu, 12 Jun 2025 11:02:41 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:
>> 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.

It looks like a latency thing. It's not that it's localhost specific,
it's that the effect is more pronounced on low-latency connections
because something, somewhere is adding a tiny delay (likely the timeout).

When I test against my router (10ms latency, how awful!), I get a 1.25x
speedup (1.2x speedup with just your timeout change).

I've also tested with IP addresses and reproduced the same results, so
it's not related to DNS lookups.


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

I'll do that today. I have a suspicion that fast requests waiting on a
single process exit early here:

https://https.git.savannah.gnu.org/cgit/git/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5562

>>  But the evidence so far points at the handling of the timeout.

I can say that we're definitely NOT waiting for the timeout: increasing
the timeout (to, e.g., 1-2s) doesn't slow things down. I suspect having
a really short timeout is causing us to abort
wait_reading_process_output early before it hits some expensive part.

Previous Next

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