[XML-SIG] Re: Re: cElementTree 0.8 (january 11, 2005)

[Daniel Veillard]

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 at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/