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: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
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 14:52:41 +0300

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

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

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

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

> This is how `url-retrieve-synchronously' behaved before
> bug#49897 changed it to work around then undiagnosed bugs in
> `accept-process-output'.

Exactly.  I'm unwilling to risk reintroducing bugs we already fixed.

Previous Next

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