bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside eldoc-d


From: Dmitry Gutov
Subject: bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside eldoc-documentation-function
Date: Fri, 15 Mar 2019 16:24:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 13.03.2019 18:49, Eli Zaretskii wrote:

- Continue typing, pause from time to time and wait for "done" to show
up in the echo area. After a little while, it will stop arriving,
because the requests will stall for some reason.

They don't stall here, they just take more time to complete.

How much more time? In my current testing, it can go up 20x. And maybe more.

So normally all 10 requests to GOOG complete in 1.1s (meaning 0.11s per request), but after some typing, it slows down and takes ~20s. That's ~1.8s per request.

At the same time, if I open a second instance of Emacs and try the scenario there, the requests start out slow already (same as in the already open instance).

But at the same time, opening www.google.com in Firefox is still fast. As well as doing it from a console with CURL ('time curl http://www.google.com' shows 0.3s).

Sounds like an external library problem, maybe?

If you do the same from an interactive function, not from eldoc, does
the problem happen there as well?

More or less. I managed to make it slower by ~20x as well.

Try this:

(defun silly-eldoc ()
  (let ((start (time-to-seconds)))
    (dotimes (i 10)
      (url-retrieve-synchronously "http://www.google.com";)
      (message "try %i" i))
    (format "done in %f" (- (time-to-seconds) start))))

(defun silly-command ()
  (interactive)
  (message "%s" (silly-eldoc)))

(global-set-key (kbd "C-o") #'silly-command)

Call the command a few time with C-o, it should run the timer and finish with calculation how much time it took to run the requests. Now:

1. Alternate between pressing C-o and C-g, with varying speeds.

The goal is to see

 error in process filter: Transfer interrupted!
 error in process filter: url-http-generic-filter: Transfer interrupted!

a few times.

2. Then see if C-o still runs to completion. If it does, and does not look slow enough, repeat 1.

BUT! I have tried to reproduce this slowdown behavior with a local server, and so far no luck. Ping to Google (or almost any other website) is 100ms from my current location, so maybe it makes a difference.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]