[pypy-dev] Playing with PyPy and Django
Tin Tvrtković
tinchester at gmail.com
Sun Feb 8 19:23:24 CET 2015
Hello,
thanks to everyone for their input (especially Maciej).
Since I've ripped out all my code from the test project, it's not a
Python 3 project anymore, so I did try PyPy 2 with it too. It's faster,
yes; the last test looked something like:
PyPy 2 20.206 [ms] (mean)
PyPy 3 27.588 [ms] (mean)
CPython 3.4 10.865 [ms] (mean)
(tried both PyPy 2.5, downloaded directly, and 2.4 from the Ubuntu PPA -
about the same.)
I don't know, maybe the admin page isn't a good test candidate since it
might do more introspective/reflective/meta stuff. I've tried doing this
same test (10k warmup requests, 100 benchmark requests) on the main page
of the site I'm working on; the results are:
PyPy 3 15.863 [ms] (mean)
CPython 3.48.668 [ms] (mean)
and I can be certain there's nothing much going on there. Just some
permission checks, grabbing some stuff from the database, checking some
query parameters and a template render.
I suppose if folks have CPU intensive stuff in their view functions
(nested for-loops etc) the optimizations PyPy can do to that far
outweigh the non-optimized Django parts; my sites generally don't though.
On 08.02.2015 18:44, Maciej Fijalkowski wrote:
> then it's used in the wrong ways in say django admin, look at
> invocations to lazy there (this is how it showed up in my profile)
>
> On Sun, Feb 8, 2015 at 5:08 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>> FWIW, I've definitely seen and worked on Django sites that got major
>> improvements out of PyPy -- both the templates and ORM are both sped up
>> substantially by it. I think we should try to fix issues as we see them,
>> before writing it off.
>>
>> FWIW: lazy does not create a new class per call of a function, it's only one
>> class per decorated function.
>>
>> Alex
>>
>> On Sun, Feb 8, 2015 at 6:59 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>> I don't know :-( not sure if fixing those issues one by one is the way
>>> to go, it's not like *this* particular code is a problem, it's the
>>> culture that breeds those sort of things
>>>
>>> On Sun, Feb 8, 2015 at 2:09 PM, Omer Katz <omer.drow at gmail.com> wrote:
>>>> Isn't there anything we can do about it?
>>>> We can open issues at the Django issue tracker if some code slows down
>>>> execution in PyPy.
>>>>
>>>> 2015-02-08 12:17 GMT+02:00 Maciej Fijalkowski <fijall at gmail.com>:
>>>>> Hi Tin
>>>>>
>>>>> I have a bit sad news for you, but essentially from what I looked at
>>>>> profling, the answer seems to be "don't use django, it has not been
>>>>> written with performance in mind". For example here (which features in
>>>>> django admin quite prominently, some stuff calls lazy() at each call):
>>>>>
>>>>>
>>>>> https://github.com/django/django/blob/master/django/utils/functional.py#L48
>>>>>
>>>>> What does it, per call that pypy does not like:
>>>>>
>>>>> * redefines classes
>>>>>
>>>>> * walks the class __mro__ and defines tons of new methods
>>>>>
>>>>> * proxies everything through a not so efficietn mechanisms
>>>>>
>>>>> Those things quite defy the purpose of the JIT - you're making tons of
>>>>> very dynamic things that pypy generally assumes is "static enough", if
>>>>> you wanted to do the same thing in C++, you would need to call gcc
>>>>> with each request, that would not be so much fun.
>>>>>
>>>>> If you really care about performance, consider swapping your web
>>>>> framework to something more performance-oriented where JIT compilation
>>>>> can help.
>>>>>
>>>>> As a side note, we (me and my company, not to be confused with PyPy
>>>>> open source project) do offer looking at proprietary code for
>>>>> benchmarking purposes as a commercial service, look at
>>>>> baroquesoftware.com
>>>>>
>>>>> Cheers,
>>>>> fijal
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Feb 7, 2015 at 1:12 AM, Tin Tvrtković <tinchester at gmail.com>
>>>>> wrote:
>>>>>> Hello, PyPy folks!
>>>>>>
>>>>>> While trying to speed up one of my Django sites, I noticed a new
>>>>>> version
>>>>>> of
>>>>>> PyPy
>>>>>> had just been released. So I grabbed a fresh download of PyPy 3
>>>>>> (since
>>>>>> this
>>>>>> is
>>>>>> a Python 3 codebase) and tried taking it out for a spin.
>>>>>>
>>>>>> However, as far as I can see, whatever I try PyPy is consistently
>>>>>> slower
>>>>>> than
>>>>>> CPython for this.
>>>>>>
>>>>>> Since this is a proprietary site, I've basically ripped out all the
>>>>>> code
>>>>>> except
>>>>>> my settings.py and my requirements; and am benchmarking the Django
>>>>>> admin
>>>>>> index.
>>>>>> The results are about the same.
>>>>>>
>>>>>> I've set up a small repo that can be used to reproduce the
>>>>>> environment:
>>>>>> https://github.com/Tinche/PyPy-Django-Playground. There's additional
>>>>>> info in
>>>>>> the README there.
>>>>>>
>>>>>> These tests have been carried out on Ubuntu Trusty, 64-bit. CPython 3
>>>>>> is
>>>>>> the
>>>>>> system Python, 3.4. PyPy has been downloaded from the official site
>>>>>> and
>>>>>> unzipped.
>>>>>>
>>>>>> So what I basically do is set up an admin session, and use the Django
>>>>>> main
>>>>>> admin
>>>>>> page. 200 warmup requests, then 100 benchmarked requests, look at the
>>>>>> mean
>>>>>> request time.
>>>>>>
>>>>>> Some results:
>>>>>>
>>>>>> Django's runserver, DEBUG mode:
>>>>>>
>>>>>> PyPy3 485.389 [ms]
>>>>>> CPython 3.4 105.777 [ms]
>>>>>>
>>>>>> Django's runserver, no debug:
>>>>>>
>>>>>> PyPy3 44.661 [ms]
>>>>>> CPython 3.4 18.697 [ms]
>>>>>>
>>>>>> Gunicorn, 1 worker, no debug:
>>>>>>
>>>>>> PyPy3 28.615 [ms]
>>>>>> CPython 3.4 13.532 [ms]
>>>>>>
>>>>>> I don't exactly claim to be an expert on benchmarking, but assuming
>>>>>> my
>>>>>> site
>>>>>> is similar to the Django admin, CPython's gonna be giving me better
>>>>>> performance.
>>>>>> Also the debug runserver performance is kinda worrying. Nobody's
>>>>>> going
>>>>>> to be
>>>>>> running this in production, but it makes development a little slower
>>>>>> and
>>>>>> more
>>>>>> annoying than it should be.
>>>>>>
>>>>>> Is there anything to make PyPy more competitive in these kinds of
>>>>>> scenarios?
>>>>>>
>>>>>> Kind regards,
>>>>>> Tin
>>>>>> _______________________________________________
>>>>>> pypy-dev mailing list
>>>>>> pypy-dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/pypy-dev
>>>>> _______________________________________________
>>>>> pypy-dev mailing list
>>>>> pypy-dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/pypy-dev
>>>>
>>> _______________________________________________
>>> pypy-dev mailing list
>>> pypy-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pypy-dev
>>
>>
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right to
>> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: 125F 5C67 DFE9 4084
More information about the pypy-dev
mailing list