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>
Cc: 78773 <at> debbugs.gnu.org, rpluim <at> gmail.com, larsi <at> gnus.org
Subject: bug#78773: [PATCH] Speedup url-retrieve-synchronously for low-latency connections
Date: Sat, 14 Jun 2025 09:25:40 -0700

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

>> From: Steven Allen <steven <at> stebalien.com>
>> Cc: rpluim <at> gmail.com, 78773 <at> debbugs.gnu.org, larsi <at> gnus.org
>> Date: Fri, 13 Jun 2025 10:45:06 -0700
>> 
>> First, the actual bug: When called with no PROCESS,
>> `accept-process-output' would wait an additional 10ms
>> (READ_OUTPUT_DELAY_INCREMENT) after successfully reading data from some
>> (any) process. `url-retrieve-synchronously' was slow for localhost calls
>> because 10ms is a long time for fast requests. This bug would add 10ms
>> of latency to every request.
>
> But it's an unneeded delay only if there's no more output from the
> subprocess during those 10 ms, isn't that so?  And we don't really
> know if all the process output was read, do we?

(discussed in the other email)

>> My SECOND patch (0772d96d, the one to process.c) fixes this
>> underlying bug by setting the timeout to 0 in this case: when we manage
>> to read data from some process and aren't waiting on any specific
>> process.
>
> But what if we are also waiting for output from other processes?  Your
> patch will slow those down, won't it?  In you case, you only care
> about a single process, but that's not so in general.

(discussed in the other email)

>> Next steps:
>> 
>> 1. The SECOND patch fixes the actual bug and should be installed to fix
>> the underlying bug (assuming I correctly diagnosed the problem/solution,
>> but I'm pretty sure I did).
>
> I disagree for now.  I need to understand better why you think it's
> TRT in the general case.

(discussed in the other email)

>> 2. Personally, I would install the FIRST patch as well as it avoids
>> returning to `url-retrieve-synchronously' until we've actually read
>> relevant data.
>
> What if url-retrieve was called for more than a single connection?
> Won't your FIRST patch cause a regression in that case?

I assume you're talking about redirects here? That's the only
multiple-process case I know about. In this case, it'll just return back
to the top of the `url-retrieve-synchronously' loop (same as it would
before) and wait on the next process.

Previous Next

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