[XML-SIG] SAX 2.0 names

THOMAS PASSIN tpassin@idsonline.com
Tue, 29 Feb 2000 15:44:09 -0500

Fred L. Drake, Jr. wrote
> Lars Marius Garshol writes:
>  > Hmmm.  That might be the way to go.  I still wonder about the speed,
>  > though.
>   If the C extension is actually available, it should be about the
> same a building a tuple; perhaps a *little* faster, but the difference
> would come out in the wash.
>  > Hmmm.  Let's chew on this a little more and hear some more opinions
>  > before deciding.
>   Agreed; I won't have time to write a bunch of new C code for a
> couple of weeks anyway.
>  > I did the benchmark I spoke of, and the results indicate that the
>  > performance differences are very small between strings and tuples.
>  > Also, how you put together the strings influences the speed a
>  > bit. Benchmark run with Python 1.5.2 on Debian GNU/Linux on a Pentium
>  > II with plenty of RAM and MHz.
>   Looks good!  As for string construction, "%s %s" % (uri, localpart)
> requires 1 malloc() more for the new string than just creating the
> tuple, and uri + " " + localpart would require the same number of
> malloc() calls, but slightly more data copying when uri isn't "".
> Very close, but both require the extra malloc() compared to just using
> a tuple.
In earlier posts I suggested tuples.  Fred and Lars' posts seem to be saying
that tuples shouldn't cause a bug performance hit, and that could possibly
be finessed anyway.  Have I summarized what you have said correctly, Fred
and Lars?

Then I think we should go with tuples, because
1) They are easy for a non-expert Python programmer to understand and work
2) they capitalize on a Python strength (nice data structures),
3) an expert can make them perform even better with extension modules, and
4) as Fred said, if the extension module were not available one could fall
back to a 100% Python implementation with practically no changes to existing

Tom P