From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/78675 Path: news.gmane.org!not-for-mail From: Antoine Levitt Newsgroups: gmane.emacs.gnus.general Subject: Re: Asynchroneous image retrieval in HTML rendering Date: Mon, 02 May 2011 23:52:28 +0200 Message-ID: <87pqo0u5wj.fsf@gmail.com> References: <87bozwfw84.fsf@gmail.com> <87r58ll8jm.fsf@gmail.com> <87liys4x04.fsf@gmail.com> <87tydewilm.fsf@gmail.com> <87liyp35fy.fsf@gmail.com> <87k4e92eyx.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1304374313 23692 80.91.229.12 (2 May 2011 22:11:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 May 2011 22:11:53 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M26977=ding+2Daccount=gmane.org@lists.math.uh.edu Tue May 03 00:11:44 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QH1LA-0002PN-Rf for ding-account@gmane.org; Tue, 03 May 2011 00:11:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1QH1L9-0002xm-Nb for ding-account@gmane.org; Mon, 02 May 2011 17:11:39 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1QH12s-0002sQ-ML for ding@lists.math.uh.edu; Mon, 02 May 2011 16:52:46 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QH12s-0001OA-0k for ding@lists.math.uh.edu; Mon, 02 May 2011 16:52:46 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1QH12q-0004CM-IR for ding@gnus.org; Mon, 02 May 2011 23:52:44 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QH12q-0008Ge-5l for ding@gnus.org; Mon, 02 May 2011 23:52:44 +0200 Original-Received: from ney92-7-78-233-218-202.fbx.proxad.net ([78.233.218.202]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2011 23:52:44 +0200 Original-Received: from antoine.levitt by ney92-7-78-233-218-202.fbx.proxad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2011 23:52:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 45 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ney92-7-78-233-218-202.fbx.proxad.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Spam-Score: -1.0 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:78675 Archived-At: 02/05/11 19:40, Lars Magne Ingebrigtsen > Antoine Levitt writes: > >> Old code: about 1min10 >> New code: about 1min30 ;) > > Hey, it does something! Since this was done with the version with the autoload bug, there was actually no difference between the two :) Yet another proof that numbers without an estimate on the error don't mean anything ... > >> That's on gwene.com.wordpress.terrytao, after rm -rf .emacs.d/url/cache >> >> Which I guess means there's a small benefit in parallelizing as much as >> possible. But then again, that's an extreme case. > > It was supposed to be slower to give a better interactive performance. > :-) Does it feel snappier now -- that is, can you read page two of one > of his articles without Emacs locking up when you hit SPC? For me, this > now seems to work adequately, while before I had to wait a longer > time. Nope, still freezes pretty badly (even with the autoload fix). > > The next thing to tackle is doing the DNS resolving asynchronously. I'm > not quite sure where to put that in the chain, though... Hm... every > call to `url-queue-retrieve' could fire up an async dns.el call, and > then the callback from that call could trigger (possible) queue > runnings. And stuff that doesn't resolve at all wouldn't hit url.el at > all. > > Yes, I think that would be workable... but dns.el only works on > Linux-like machines, so it feels kinda yucky to rely on that. > > If only somebody could implement an async C-level resolver. :-) Sorry I'm not taking you up on that, but any knowledge I might have once had about asynchroneous coding is long gone, and the only thing I remember about it is "danger, will robinson" ;) I might end up attempting to have a go at it if it becomes too annoying, but don't hold you breath.