From: Tassilo Horn <tsdh@gnu.org>
To: Robert Pluim <rpluim@gmail.com>
Cc: "Adam Sjøgren" <asjo@koldfront.dk>, ding@gnus.org, emacs-devel@gnu.org
Subject: Re: Rendering regression in Gnus with gnus-treat-from-gravatar
Date: Wed, 22 Apr 2020 16:25:34 +0200 [thread overview]
Message-ID: <87r1wfsild.fsf@gnu.org> (raw)
In-Reply-To: <m27dymm0a5.fsf@gmail.com> (Robert Pluim's message of "Sat, 11 Apr 2020 18:53:38 +0200")
Robert Pluim <rpluim@gmail.com> writes:
Hi Robert and Adam,
> Adam> Robert writes:
> >> The new version doesnʼt do any more gravatar lookups than the
> >> old one, but it does by default do some DNS lookups. Is it
> >> better if you customize 'gravatar-service' to one of the other
> >> options?
>
> Adam> Of the three possible options for gravatar-service:
> Adam> gravatar, unicornify, libravatar only the last, and default,
> Adam> libravatar exhibits the problem.
>
> OK, so itʼs the DNS. The libravatar method does a bunch of DNS
> queries, and those can be slow, and they're done for every article.
I have the same problem as Adam. And it happened two or three times
that upon clicking a message, Emacs started consuming 100% CPU and stuck
at least 30 seconds before I hit C-g. At one occurrence, I attached GDB
after waiting at least 30 seconds for the full message to appear and on
the bottom of the call stack was
dns-query
accept-process-output
Hm, that must be that while loop in dns-query but given the values of
step and times, I cannot see how that could block for so long. And
usually, it doesn't.
And in the ususal case, it is just slow in the sense of maybe 2-5
seconds. And in those normal cases, it's not so much the dns query but
the TLS negotiation with seccdn.libravatar.org (in case the DNS lookup
found no custom gravatar url).
Here's a profiler report gathered with:
(progn
(profiler-start 'cpu)
(gravatar-retrieve-synchronously "tsdh@gnu.org")
(profiler-report)
(profiler-stop))
--8<---------------cut here---------------start------------->8---
- command-execute 33 100%
- call-interactively 33 100%
- funcall-interactively 33 100%
- eval-last-sexp 33 100%
- elisp--eval-last-sexp 33 100%
- eval 33 100%
- progn 33 100%
- progn 33 100%
- gravatar-retrieve-synchronously 32 96%
- let 32 96%
- save-current-buffer 25 75%
- set-buffer 25 75%
- if 25 75%
- url-retrieve-synchronously 25 75%
- url-retrieve 24 72%
- url-retrieve-internal 24 72%
- url-https 24 72%
- url-http 24 72%
- url-http-find-free-connection 24 72%
- url-open-stream 24 72%
- open-network-stream 24 72%
- network-stream-open-tls 24 72%
- open-gnutls-stream 24 72%
- gnutls-negotiate 24 72%
- gnutls-boot-parameters 1 3%
- gnutls-trustfiles 1 3%
- gnutls--get-files 1 3%
file-expand-wildcards 1 3%
+ accept-process-output 1 3%
- gravatar-build-url 7 21%
- format 7 21%
- funcall 7 21%
- gravatar--service-libravatar 7 21%
- let 7 21%
- unwind-protect 7 21%
- progn 7 21%
- if 7 21%
- let 7 21%
- catch 7 21%
- let 7 21%
- while 7 21%
- let 7 21%
- let* 7 21%
- dns-query 7 21%
- sit-for 6 18%
redisplay 3 9%
read-event 3 9%
--8<---------------cut here---------------end--------------->8---
Bye,
Tassilo
next prev parent reply other threads:[~2020-04-22 14:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-11 13:18 Rendering regression in Gnus with gnus-treat-from-gravatar Adam Sjøgren via "Emacs development discussions.
2020-04-11 14:15 ` Robert Pluim
2020-04-11 15:16 ` Adam Sjøgren
2020-04-11 16:53 ` Robert Pluim
2020-04-14 13:14 ` Robert Pluim
2020-04-14 15:46 ` Eli Zaretskii
2020-04-14 17:32 ` Adam Sjøgren
2020-04-15 8:15 ` Robert Pluim
2020-04-15 9:41 ` Eli Zaretskii
2020-04-15 10:13 ` Robert Pluim
2020-04-15 11:38 ` Eli Zaretskii
2020-04-15 11:55 ` Robert Pluim
2020-04-15 12:01 ` Eli Zaretskii
2020-04-15 13:54 ` Robert Pluim
2020-04-15 14:12 ` Eli Zaretskii
2020-04-15 14:20 ` Robert Pluim
2020-04-22 14:25 ` Tassilo Horn [this message]
2020-04-22 14:39 ` Tassilo Horn
2020-04-22 14:56 ` Robert Pluim
2020-04-22 17:32 ` Tassilo Horn
2020-04-22 14:59 ` Robert Pluim
2020-04-22 17:01 ` Tassilo Horn
2020-04-22 17:23 ` Robert Pluim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r1wfsild.fsf@gnu.org \
--to=tsdh@gnu.org \
--cc=asjo@koldfront.dk \
--cc=ding@gnus.org \
--cc=emacs-devel@gnu.org \
--cc=rpluim@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.