I didn't realize this existed as well; however, I would suspect that in the DBI->XML->XSLT path, the choice of which parser or XSLT library that you use is going to have some, but not a significant impact on the overall speed, assuming that, as with LibXSLT and XML::Parser, there's a non-perl component. As demonstrated by the two pure-perl routes, any significant processing of XML is going to need a boost by having pre-compiled code available for at least parsing the system.

However, I think I'll add the XML::XSLT case as well as skipping the DOM->string->DOM conversion that I do as gellyfish mentioned in reply to Matts response above, as additional tests, just for completeness. (I could also probably improve the xslt sheet itself, for the row coloring code doesn't seem to be overly efficient).

I also understand that GNOME's LibXML (which XML::LibXML uses) is not fully complient with recent W3C specs, so that may be a notch against it, as I'd expect a fully complient library to be a bit more rigorous and thus more CPU demanding.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"It's not what you know, but knowing how to find it if you don't know that's important

There are no known areas where LibXML/LibXSLT are not fully compliant with the relevant W3C specs (they're even authored by the W3C!). If you do know of areas where they fall down on this please do let me know and I'll forward the info on to Daniel.