On Sat, Feb 18, 2012 at 11:48 AM, Stefan Behnel <stefan...@behnel.de> wrote: > Maciej Fijalkowski, 18.02.2012 10:35: >> On Sat, Feb 18, 2012 at 11:27 AM, Stefan Behnel wrote: >>> Given that XML processing is currently slower in PyPy than in CPython, I >>> don't think that's all that bad. Users can still switch their imports to >>> ElementTree if they only want to push XML out and I imagine that lxml would >>> still be at least as fast as ElementTree under PyPy for the way in. >> >> Are you sure actually? > > I'm sure it's currently much slower, see here: > > http://blog.behnel.de/index.php?p=210 > > I'm not sure the quickly patched lxml is as fast in PyPy as it is in > CPython, but there is certainly room for improvements, as I mentioned > before. A substantial part of it runs in properly hand tuned C, after all, > and thus doesn't need to go through cpyext or otherwise talk to PyPy. > > Stefan > > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > http://mail.python.org/mailman/listinfo/pypy-dev
Can you please send me or post somewhere numbers? I'm fairly bad at trying to deduce them from the graph (although that doesn't change that the graph is very likely more readable). I'm not sure there are easy ways to optimize. Sure cpyext is slower than ctypes, but we cannot achieve much more than that. Certainly we cannot do unboxing (boxes might be only produced to make cpyext happy for example). Unless I'm misunderstanding your intentions, can you elaborate? I somehow doubt it's possible to make this run fast using cpyext (although there are definitely some ways). Maybe speeding up ElementTree would be the way if all we want to get is a fast XML processor? I doubt this is the case though. I'm waiting for other insights, I'm a bit clueless. Cheers, fijal _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
