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

[Tassilo Horn]

Robert Pluim <address@hidden> writes:

Hi Robert,

>     Tassilo> And in the ususal case, it is just slow in the sense of
>     Tassilo> maybe 2-5 seconds.  And in those normal cases, it's not
>     Tassilo> so much the dns query but the TLS negotiation with
>     Tassilo> seccdn.libravatar.org (in case the DNS lookup found no
>     Tassilo> custom gravatar url).
>
>     Tassilo> Here's a profiler report gathered with:
>
>     Tassilo> (progn
>     Tassilo>   (profiler-start 'cpu)
>     Tassilo>   (gravatar-retrieve-synchronously "address@hidden")
>     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

I guess so as it does the lookups on every message and every mail
address where it would suffice to do it once per unique domain part of
mail addresses.

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

Indeed, I've tried using "http://cdn.libravatar.org/avatar"; which was
way faster.  Do you know what might slow down TLS negotiation so much?
Now when I think about it, I'd also say that accessing GNU ELPA for
package upgrades became slower, too.  But browsing the web seems to work
normally but I think Firefox or Epiphany might not use gnutls...

> 3. Apply the gravater caching patch from Philip K
>
> I suspect [2] there would give the biggest improvement, given your
> profile report.

Maybe.  But if I understood your reply to Adam on ding, only the DNS
lookups block seeing the complete Gnus article, right?  The retrieval is
asynchronous anyway which just means the gravatar images might take some
time to pop up in the article buffer.  If that is true, then I'd only
care about the DNS part.

Bye,
Tassilo