GNU bug report logs -
#78773
[PATCH] Speedup url-retrieve-synchronously for low-latency connections
Previous Next
Full log
Message #20 received at 78773 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 2 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.