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… :-)
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?

- Yellow background
- Green background
- Green HR
- Green bg LI (the star should be on green bg)
- red on white
- table must have pink borders
- table must have black background
- first left cell must be red on black
- second left cell must be red on blue
- third left and right cells should be red on orange
- white text on white background
- orange text on orange background
- white text on white background (same old)
- 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))))
> => (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...

0.02 on 3 in 1000 execution times… Well… :) 

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

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info