From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/74834 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: [PATCH] shr: render table with style Date: Tue, 07 Dec 2010 17:34:27 +0100 Organization: Programmerer Ingebrigtsen Message-ID: References: <1291656608-16263-1-git-send-email-julien@danjou.info> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1291739727 16311 80.91.229.12 (7 Dec 2010 16:35:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Dec 2010 16:35:27 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M23190@lists.math.uh.edu Tue Dec 07 17:35:23 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 1PQ0Vf-0004aj-5c for ding-account@gmane.org; Tue, 07 Dec 2010 17:35:23 +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 1PQ0VF-0004VB-CN; Tue, 07 Dec 2010 10:34:57 -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 1PQ0VD-0004Us-Sm for ding@lists.math.uh.edu; Tue, 07 Dec 2010 10:34:55 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PQ0Uz-0004Mr-Gi for ding@lists.math.uh.edu; Tue, 07 Dec 2010 10:34:55 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1PQ0Ux-0004iC-00 for ; Tue, 07 Dec 2010 17:34:39 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PQ0Ux-00049m-2l for ding@gnus.org; Tue, 07 Dec 2010 17:34:39 +0100 Original-Received: from cm-84.215.34.171.getinternet.no ([84.215.34.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Dec 2010 17:34:39 +0100 Original-Received: from larsi by cm-84.215.34.171.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Dec 2010 17:34:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 67 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.215.34.171.getinternet.no Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEULBxiIoqMTFi318N4+ f487ZHQeNEzeFoOCAAACRklEQVQ4jW2UTY/bIBCGWaT1uRSlZwfF3Knl3hsB5+CAzykF/v9P6Du2 k/WqOyLI8TNfzHhg49di2CiE3B4/EzZO40am/4AQ4w4MNLCEMJvFGM4nOU5Tmsz9LzwHedqBNEaM kyGRQkp5Xy2+EkHglIILApJScvil6FINAD1jrLP2xp5SfGttZAaPSlk7M96U4lq36FNdVsB5H+1V FWttgjJAShtQ9DLidYp2OQC2AusWpWq0KfoY3QY4IzBz3VoljWh3wBj8eHKpibialh1w6D04AATq 2A+AcR2tV+pibX6BjjxpS4HUcAAc4MopAbjRRHdAf64q5ZpUzHjOOu+gAWgXPW91PlhwjVpdL3NL Q43zGqPfqqs2EFP/Hq+VUlMfwGkbXa12LnZuFGNci4h8MiASA2httVgBlaTQcg22remnKwDHrQce rD8AHunQHZUJLTsAVNdVlFGr6HBUVBngsRXxthT70PGqLw7nGz6AtoN9FDR9NdkB59Z1VsXHxet0 BdAEbmsRfYfW9sNN1xxfgKsOFq7MPCtdVNld3ViXB/p6+tYhH6eKfwJO7Sx+qYOuuvlyiAEwZO0u rWU20AnPAN8Y6wHi0rei5qwb9YnA9w3wJc1lzi0Ve1PqDcCk3KPc2eu5KPWOLj96dj5OFA2POP0O AuMTMOeS5s7csUaJ/eMCkOYk7iOG7QSv4oeRr5sh0CwKic2Il1uzxZDj51sD472CsE62ESbInwJO w323gMICZ3+mIH+dw1sQSGIHcGYC7ZIiIlHzDxwq5mrPtpSYAAAAAElFTkSuQmCC Mail-Copies-To: never X-Now-Playing: Pink Industry's _Who Told You, You Were Naked?_: "Two Culture's" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:27bxC4GjwXD88DgcERD7yrpRis0= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:74834 Archived-At: Julien Danjou writes: > I agree, but I'm just suggesting to optimize things based on real data > rather than throwing "it will be slower that way". Real data is great, but it takes a lot of typing to get to it. Thank you for doing so. :-) > It's obvious that it will be slower if we add more code (thanks). But if > the table code execution time (you say it's slow) and what I'm proposing > to add are having a 90/10 execution time ratio, arguing that adding more > stuff is bloating the execution time is not really helpful. :-D 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've used the following data example to test the rendering: Nice. > 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? > Benchmark runs with: > (benchmark-run-compiled 100 > (shr-insert-document > (libxml-parse-html-region > (point-min) (point-max)))) > > With my patch the code is 58 % slower but passes twice more tests (and > probably more, actually, I did not bother to make the numbers show how > lame the current code is :-P). 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)))) => (3.0290269999999997 19 1.0066839999999786) After adding the -tag-table and -render-td colourisations (that should be a word): => (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... 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... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen