& XSLT 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/
veillard@[...].com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
XML-SIG maillist  -  XML-SIG@[...].org
http://mail.python.org/mailman/listinfo/xml-sig