Re: Asynchroneous image retrieval in HTML rendering

[Antoine Levitt <antoine.levitt@gmail.com>]

02/05/11 16:30, Lars Magne Ingebrigtsen
> Antoine Levitt <antoine.levitt@gmail.com> writes:
>
>> That doesn't change much for my test cases, so I guess the DNS lookup is
>> indeed the bottleneck.
>
> Have you verified that the DNS lookup is really the problem?  Because I
> have more theories.  :-) (Or, as scientists call it, "guesses".)

No, just that your recent commit didn't change anything. But the groups
that have trouble, such as gwene.fr.lemonde.blog.vidberg, are also
those whose DNS is slow/buggy.

>
> One thing about the async image retrieval is that it's massively
> parallel.  If there's 500 images in the article, Gnus will call
> `url-retrieve' 500 times in rapid succession, which will then fire off
> 500 HTTP connections (in parallel, more or less).
>
> I suspect that Emacs doesn't really like having this number of async
> socket sentinels going on at the same time, which means that the main
> Emacs thread gets no CPU time, which gives us interactive pauses.

That doesn't seem likely: I also get freezes in groups with just one or
two images. And in this case, doesn't that rather mean that there's
something wrong with the scheduler from emacs/the OS?

>
> (And it's really rude towards the server.  It's basically a one-Emacs
> DoS attack.)

Isn't that already what all browsers do?