From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/74835 Path: news.gmane.org!not-for-mail From: Julien Danjou Newsgroups: gmane.emacs.gnus.general Subject: Re: [PATCH] shr: render table with style Date: Tue, 07 Dec 2010 18:00:48 +0100 Message-ID: References: <1291656608-16263-1-git-send-email-julien@danjou.info> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: dough.gmane.org 1291741272 24506 80.91.229.12 (7 Dec 2010 17:01:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Dec 2010 17:01:12 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M23191@lists.math.uh.edu Tue Dec 07 18:01:08 2010 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 1PQ0uY-0002Ka-FA for ding-account@gmane.org; Tue, 07 Dec 2010 18:01:06 +0100 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 1PQ0uM-0004cY-Sn; Tue, 07 Dec 2010 11:00:54 -0600 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 1PQ0uL-0004cF-1E for ding@lists.math.uh.edu; Tue, 07 Dec 2010 11:00:53 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PQ0uJ-0004V8-Hr for ding@lists.math.uh.edu; Tue, 07 Dec 2010 11:00:52 -0600 Original-Received: from coquelicot-s.easter-eggs.com ([213.215.37.94]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1PQ0uI-00054Y-00 for ; Tue, 07 Dec 2010 18:00:50 +0100 Original-Received: from cigue.easter-eggs.fr (cigue.easter-eggs.fr [10.0.0.33]) by rose.easter-eggs.fr (Postfix) with ESMTPS id 650D41415E for ; Tue, 7 Dec 2010 18:00:45 +0100 (CET) Original-Received: from jdanjou by cigue.easter-eggs.fr with local (Exim 4.72) (envelope-from ) id 1PQ0uH-00032W-BI for ding@gnus.org; Tue, 07 Dec 2010 18:00:49 +0100 Mail-Followup-To: ding@gnus.org In-Reply-To: (Lars Magne Ingebrigtsen's message of "Tue, 07 Dec 2010 17:34:27 +0100") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:74835 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 07 2010, Lars Magne Ingebrigtsen wrote: > I find that in Gnus development, you really can't keep carping > "developers, develop...", er, I mean, "speed, speed, speed" enough. One > adds one more obscure extra functionality because it's nice to have, and > then you find that everything is 50% slower than before. It's happened > a lot... and mostly with code I write myself. :-) I tend to agree, but I do not always suffer from it, so=E2=80=A6 :-) OTOH, sometimes, we should just go on emacs-devel and yield that elisp is too slow maybe. ;) >> I've counted 15 color rendering points in it that should be rendered >> correctly. Based on that, I've benchmarked the execution time and the >> number of rendering point correctly done on current master version and >> with my patched version. > > I'm not sure I'm seeing all the rendering points, but the obvious ones > were the table/td/td {b,f}gcolor ones, right? =2D Yellow background =2D Green background =2D Green HR =2D Green bg LI (the star should be on green bg) =2D red on white =2D table must have pink borders =2D table must have black background =2D first left cell must be red on black =2D second left cell must be red on blue =2D third left and right cells should be red on orange =2D white text on white background =2D orange text on orange background =2D white text on white background (same old) =2D blue text on white background And one I forgot. Or it's 14. > I just did the obvious thing and altered -tag-table and -render-td to do > colourisation like -tag-font, and, tada, with the following and your > test HTML. Before: > > (let ((doc > (save-excursion > (libxml-parse-html-region > (goto-char (point-min)) (search-forward "\n\n"))))) > (benchmark-run-compiled 1000 (with-temp-buffer > (shr-insert-document doc)))) > =3D> (3.0290269999999997 19 1.0066839999999786) > > After adding the -tag-table and -render-td colourisations (that should > be a word): > > =3D> (3.0097929999999997 19 1.0296220000000034) > > So that's, er, faster. Ok, `benchmark-run-compiled' may not be the most > precise benchmarking tool in the world, but... 0.02 on 3 in 1000 execution times=E2=80=A6 Well=E2=80=A6 :)=20 > I didn't try to do TR handling, though, so yours is more ACID-ey. Or > bordercolor, but I don't really think the latter matters much... Hehe. I understand, but where to draw the line is complicated then. What we are doing is not that complicated after all, so I do not understand why things are so slow, but well. As I said, that's your call. You can still hack on your version to try to pass my ACID test. But then I'll make the test harder so you'll end up crazy with your special casing everywhere and I'll laugh at you. Or just embrace the force and use my version which should work with everything. /me raises his hand in front of Lars and says: This is not the droid you're looking for. =2D-=20 Julien Danjou // =E1=90=B0 http://julien.danjou.info --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkz+aEEACgkQpGK1HsL+5c0bswCfbwwe35WXMAcaDyGDqERLub6d ZUsAni9OfQMZEWZWtlBLmjEXJPr64b3Q =t6SW -----END PGP SIGNATURE----- --=-=-=--