Re: Rendering regression in Gnus with gnus-treat-from-gravatar

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Wed, 22 Apr 2020 16:25:34 +0200, Tassilo Horn <tsdh@gnu.org> said:

    Tassilo> I have the same problem as Adam.  And it happened two or three times
    Tassilo> that upon clicking a message, Emacs started consuming 100% CPU and stuck
    Tassilo> at least 30 seconds before I hit C-g.  At one occurrence, I attached GDB
    Tassilo> after waiting at least 30 seconds for the full message to appear and on
    Tassilo> the bottom of the call stack was

    Tassilo>   dns-query
    Tassilo>   accept-process-output

    Tassilo> Hm, that must be that while loop in dns-query but given the values of
    Tassilo> step and times, I cannot see how that could block for so long.  And
    Tassilo> usually, it doesn't.

Iʼve seen it take 5 seconds with slow DNS just to do the DNS
lookup. There might be multiple issues here.

    Tassilo> And in the ususal case, it is just slow in the sense of maybe 2-5
    Tassilo> seconds.  And in those normal cases, it's not so much the dns query but
    Tassilo> the TLS negotiation with seccdn.libravatar.org (in case the DNS lookup
    Tassilo> found no custom gravatar url).

    Tassilo> Here's a profiler report gathered with:

    Tassilo> (progn
    Tassilo>   (profiler-start 'cpu)
    Tassilo>   (gravatar-retrieve-synchronously "tsdh@gnu.org")
    Tassilo>   (profiler-report)
    Tassilo>   (profiler-stop))

gravatar does those retrieves asynchronously, but that won't change
the call graph, I donʼt think.

Would it make sense to

1. Use dns-query-cached
2. Switch gravatar to use http rather than https by default, with a
user option to use https (Iʼm assuming this speeds things up)
3. Apply the gravater caching patch from Philip K

I suspect [2] there would give the biggest improvement, given your
profile report.

Robert