On Thu, Jan 13, 2005 at 09:35:18PM +0100, Fredrik Lundh wrote: > As someone just pointed in private mail, libxml2 may be on par on the parsing > side, but since cElementTree creates *Python* objects, it has a major advant- > age over libxml2 once you start digging into the tree from Python. cElement- > Tree doesn't have to create any proxy objects; everything you can reach is al- > ready a Python object.
I'm following from the distance, I don't care about a speed war so I won't comment on any benchmark :-). If you can build a C layer dedicated to Python you should be able to get better performances than a generic engine with autogenerated python bindings, and yes the proxy objects are a bit nasty, I'm not claiming the bindings are perfect (I would be toasted very quickly here I'm sure :-). I't also refreshing to see somone from the Python side caring about performances (now I'm sure I'm will get some fan mail ;-) Seriously, with respect to performances one of the trouble I have seen when doing a bit of profiling is that interning strings, i.e. the process of taking string coming from C and turning them into Python string objects, to be extremely costly, I don't know if it's the hash function or the way the string hash works but it was one of the biggest cost when I tried (with python 2.3 or 2.2 I can't remember precisely when it was). Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ XML-SIG maillist - XML-SIG@python.org http://mail.python.org/mailman/listinfo/xml-sig
