Hi Martijn, Martijn Faassen wrote:
Stefan Behnel wrote:
I just ran a slight variant (doesn't print, builds list) of Uche's OT benchmark on
And another difference is that you don't actually measure the overhead of the Python interpret startup, correct? :)
Uh, well, was that supposed to be in there, too? :)
I'm pleasantly surprised lxml_findall() now appears to have reached parity with cET in this test; it used to be that cET was quite a bit faster in my old measurements. Can you identify which tuning effort had this effect, or this due to a slightly different benchmark? Last I did a similar check we were still half the speed:
I'm not quite sure. I changed a lot of bits everywhere, in the XPath code, the proxy code and the Element creation code. Guess it was a mixture of all of them. There's quite a bit of fast-paths in there now that make a difference when you ask for a lot of elements. BTW, note that there is even an element class lookup for ns/name involved in each element creation. Thus, the tests would yield similar timings with custom per-tag Python classes for elements. That's another thing ElementTree can't give you.
http://faassen.n--tree.net/blog/view/weblog/2005/01/17/0
Heh, the Uche quote on that page has been proven wrong, right? :)
Totally. What does that guy know anything about, anyway? :] (uh, he's not listening, is he?) :) I'd actually like to see something about lxml on "xml.com". lxml has been in a pretty usable state for quite a while now and is even nearing feature-completeness. Maybe we should just get out 1.0 and send Uche a friendly mail. *wink* Stefan