Hi All I noticed pickle in pypy is slower than cPickle in python (faster than pickle in python). Is it a feature? Regards gelin yan
On Sat, Jan 31, 2015 at 4:32 PM, Gelin Yan <dynamicgl@gmail.com> wrote:
the feature is that nobody had to write it in C, yet it's faster. isn't that cool?
-- Luciano Ramalho Twitter: @ramalhoorg Professor em: http://python.pro.br Twitter: @pythonprobr
Hi, On 31 January 2015 at 20:43, Luciano Ramalho <luciano@ramalho.org> wrote:
Our cPickle is written in pure Python: ``from pickle import *`` The speed of that is a bit slower than CPython's optimized C version, yes. If someone really cares about the performance of cPickle he could attempt to port it to RPython code. Likely, you need to start from CPython's cPickle module and get the same C-ish style, instead of starting from pickle.py. In this case the goal is only performance, so there wouldn't be much point if the result is only a little bit faster than pickle.py-with-the-JIT-applied-to-it. Finally, note that while we could hope getting up to the same speed as CPython, we can't hope to be much *faster* than C code that is not repeatedly interpreting anything; there is very little overhead to remove. A bientôt, Armin.
On Sat, Jan 31, 2015 at 4:32 PM, Gelin Yan <dynamicgl@gmail.com> wrote:
the feature is that nobody had to write it in C, yet it's faster. isn't that cool?
-- Luciano Ramalho Twitter: @ramalhoorg Professor em: http://python.pro.br Twitter: @pythonprobr
Hi, On 31 January 2015 at 20:43, Luciano Ramalho <luciano@ramalho.org> wrote:
Our cPickle is written in pure Python: ``from pickle import *`` The speed of that is a bit slower than CPython's optimized C version, yes. If someone really cares about the performance of cPickle he could attempt to port it to RPython code. Likely, you need to start from CPython's cPickle module and get the same C-ish style, instead of starting from pickle.py. In this case the goal is only performance, so there wouldn't be much point if the result is only a little bit faster than pickle.py-with-the-JIT-applied-to-it. Finally, note that while we could hope getting up to the same speed as CPython, we can't hope to be much *faster* than C code that is not repeatedly interpreting anything; there is very little overhead to remove. A bientôt, Armin.
participants (3)
-
Armin Rigo -
Gelin Yan -
Luciano Ramalho