bzr-sax actually uses xml.sax interface

[Robert Collins]

On Fri, 2005-10-21 at 00:47 -0500, John A Meinel wrote:

> Using the same code bases, I developed this plot:
> http://bzr.arbash-meinel.com/other/timing-2/TimeRevstore2Weave.png
> 
> In it, you can see that the "real sax" is negligably slower than the
> iterparse (using cElementTree) version. While bzr.dev is much slower.
> This is mostly because I've reformatted the revision xml to make it
> create better weaves (as my other posts indicated).
> 
> So I would have to say our #1 priority is to get the Weave objects faster.
> 
> Is there interest in having some compiled C extensions, for handling the
> performance critical portions? Python distutils has decent support for
> that sort of thing, it means people would need to do "python setup
> install" before using bzr, rather than just having all python code. But
> it seems like we have a couple of very obvious performance areas. Though
> perhaps the append-only weave would fix some of it, I'm not convinced
> that it would.
> Mostly because for a lot of texts, (especially inventory) you are pretty
> likely to have lines that cross lots of revisions. So when you extract
> them, you are still going to have to go way back in the file, and
> rebuild the current text from a lot of previous chunks.

'setup.py build' will build such extensions without installing them,
FWIW.

Yes, there is definite interest in C extensions for performance critical
areas. Martin and I have discussed this quite a few times :). I think
both of us would like to leave heavy performance optimisation until we
are really feature complete - its much easier to mutate design in pure
python.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051023/df17c0db/attachment.pgp