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 10:27:13 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> With this one change, this code goes back to being as slow as it was before.
>
> What happens if you leave the 1st argument of accept-process-output at
> its current nil value, but change the 2nd argument to be 0.005 instead
> of 0.05 (i.e., 10 times smaller)?

Now testing with:

    emacs -Q --load=url.el --batch --eval \
        "(benchmark 100 '(url-retrieve-synchronously \"http://127.0.0.1:8000\"))"

- Changing the timeout from 0.05 to 0.005 drops the time from 1.25
  seconds to 0.63 seconds (~2x faster).
- My patch drops it to 0.056  (22x faster in a clean environment).

However note: changing the timeout from 0.05 to 0.005 makes the wait
loop spin 6 times for higher latency (non-localhost, ~40ms) requests whereas it
loops exactly once with the default timeout.

> Also, how many other sub-processes (of any kind, not just network
> processes) do you have in that session when you are testing this
> issue?

From list-processes, 13-14 when testing this originally (including network
processes, listening sockets, etc.).

>> However, the patch in question also changed the rest of
>> `url-retrieve-synchronously' so I'm hoping the issue lies elsewhere?
>
> Unfortunately, I doubt that we will get any useful answers to this
> question.  We need to understand better why asking for output from a
> single process has such a dramatic effect in your case with localhost
> requests.  If it happens only with localhost requests, perhaps we
> could make some changes only for that case.

Testing with a server with a 30ms latency (tested with "emacs -Q"), I get:

1. A 1.4x speedup with my patch.
2. A 1.3x speedup by simply changing the timeout.

But there's a lot more noise in the higher-latency tests.

Previous Next

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