Skip Montanaro wrote:
mal> I think that the sgmlop design is sufficiently simple and easy to mal> extend to make it a good candidate for inclusion. Sure, we'll get mal> bug reports, but why not add sgmlop marked as experimental to the mal> core in order to get it stabilized and bug-fixed ?!
I would be happy to sgmlop added to the core. The xmlrpclib encoding and decoding do need some sort of C-based acceleration to be usable:
% python testxmlrpc.py testing with xmlrpclib 0.9.8 using FastParser 415 dumps per second 106 loads per second disabling fast parsers in xmlrpclib using SlowParser 412 dumps per second 16.1 loads per second
FWIW, the xmlrpclib delivered with Python is substantially slower dumping data than the 0.9.x versions that have been around awhile, though its decoding performance degrades less without sgmlop. Compare the above with this:
% PYTHONPATH=~/misc/python/python2 python testxmlrpc.py testing with xmlrpclib 1.0b3 using SgmlopParser 229 dumps per second 94.3 loads per second disabling fast parsers in xmlrpclib using ExpatParser 231 dumps per second 76.8 loads per second
I haven't had or taken the time to investigate the difference yet.
Hmm, you cannot really compare these numbers though, since the two runs use two different sets of parsers. Have you checked using SgmlopParser with the 0.9.8 version of xmlrpclib ? There's also a project on SF called py-xmlrpc which uses a C implementation as basis and is said to be much faster than xmlrpclib (at least that's what they quote on their web-page). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/