On Thu, Dec 10, 2015 at 7:52 PM, Alexandru Damian <[email protected]> wrote:
> Hi Russ, > > Thanks for coming back to me so quickly. > > On Thursday, December 10, 2015 at 12:30:03 AM UTC, Russell Keith-Magee > wrote: >> >> HI Alex, >> >> On Wed, Dec 9, 2015 at 9:57 PM, Alexandru Damian <[email protected]> >> wrote: >> >>> Hi, >>> >>> I've compiled the django.template.{base,context,context_processor} >>> modules with cython in order to speed up template rendering. >>> >>> I've come to the conclusion that this is needed after profiling long >>> page loads that had the data from the database returned in 10-50 ms, >>> but the page would take seconds to complete - especially *admin change >>> views* with lots of inlines. >>> >> >> If you’re seeing admin pages taking *seconds* to render, and the database >> is truly taking 10-50ms, there’s something going *very* wrong here. Can you >> share your profile data? >> > > I cProfile-instrumented *def get_response() *in *django/core/handlers/base.py > *without (vanilla django) and with cemplate, posted the results here: > > https://github.com/ddalex/django-cemplate/tree/master/profile_data > > Both profiles are with all caches primed. Please compare time spent in > django/template/base.py in vanilla (0.773 seconds) and cemplate (0.288) > seconds. > >> >> >>> I am seeing a 13% decrease in page rendering time across the board, >>> obviously passing all django tests. >>> >> >> Have you tried running PyPy instead? The reports I’ve seen suggest you’ll >> get a *lot* more than a 13% speedup. >> > > Looked at pypy first; unfortunately, not all the modules we are using are > pypy-compatible. > >> >> To make this easy to deploy I've compiled it as a drop-in replacement >>> (targeting django 1.8.7) that uses import hooks (PEP 302) >>> to replace targeted modules on the fly. >>> >>> The sources/releases are here: https://github.com/ddalex/django-cemplate >>> >>> Can you please advise on how to continue this work ? >>> I feel that maintaining separate trees for each Django release is not >>> scalable on my part. >>> >> >> It’s difficult to say without knowing what you’re proposing. Is there >> some change you’d like to see merged into Django? Some API hook that you’d >> like to add to make your life easier? >> >> > I am thinking of cythonizing parts of django (e.g. the modules that I am > modifying here) - this will bring .c compilation on install, but will make > code faster in the framework, where it is likely that nobody is modifying > it. It brings in an extra dependency on cython for developers. What is your > take on this ? > If you’re proposing that Django use Cython by default, I have to say that I’m not especially enthusiastic about the idea. I’m not a huge fan of Cython - I’ve found it to be a bunch of headaches every time I’ve tried to use it, and based on the data you’re presenting, a 13% performance boost isn’t enough to get me excited. If you’re proposing a mechanism by which someone who wants to use Cython can opt-in - I might be more inclined; but I’d need to see what the maintenance overhead would be for the core team. I’d be a *lot* more interested in providing some sort of hook so that Cython support can be maintained externally, rather than by the core team. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq8486_p7Mb-v3%3DTfyQ5-u9eJYkcO-U4KJBjW-1%3DGQjOxeeQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
