On Thu, Sep 16, 2010 at 3:05 PM, akaariai <akaar...@cc.hut.fi> wrote: > Is there any continuous speed testing done for Django? It would be > nice to see how performance of Django is evolving. For example while > working on ticket #14290, seeing how my changes to utils/translation/ > __init__.py affect other parts of the framework would be useful. In > general, speed testing should expose performance problems early, so > that design of features can be changed before the feature goes into a > release. > > If there is no continuous benchmarking done at the moment, maybe using > Codespeed (http://wiki.github.com/tobami/codespeed/) could be > considered. It is the framework used for http://speed.pypy.org, and it > is built using Django. > > If there is need for this kind of work, I am volunteering to do some > work. That is, set up Codespeed and do some simple tests. I haven't > tested integrating Codespeed with Django yet, so it is possible that > Codespeed is not useful in this set up. I would like to integrate it > with git, so that it would be easy to do speed testing of your own > development branches. In SVN this is hard to do, if I am not > mistaken... > > I am thinking of implementing the following tests (as time permits): > > Template rendering, simple case: build a table of, say 1000 x 10 cells > using for loops. > > Template rendering, forms: build a large form (possibly with FormSets) > and use that in a template. Maybe both with {{ form.as_table }} and > iterating through the form. This would test form rendering, not > initialization. > > Template rendering, real world case: Use {% extends %}, {% include %}, > {% trans %}... blocks, that is, build a simple template that reflects > real world usage. > > QuerySet building: Simple QuerySet building: > Foo.objects.filter(pk=id). Complex QuerySet building (couple of filter > operations, with some joins), maybe order by etc. > > Object creation: Just create a bunch of Model objects. A few cases > here, simple object (only id) creation, complex object (many fields) > creation, objects with foreign keys, inheritance and deferred fields > object creation. > > Realistic use case: Make a request to the framework and go through all > the parts of building the response, that is, make a request to > runserver. However, do not use database queries. > > Regression tests: Go through trac and look for speed tests attached to > tickets. > > This is probably a lot of work, but I would like to give it a try. > Comments?
Do we have a continuous performance benchmark at present? No. Would it be worth having one? Certainly. There's a long standing ticket proposing just such a change: http://code.djangoproject.com/ticket/8949 And there was a sprint earlier this year that started developing a benchmark set that could be used; results so far can be found here: http://github.com/jacobian/djangobench However, there's still a lot of work to do to build up the benchmark set and deploy it in a continuous integration environment. I'm not aware of anyone specifically coordinating this benchmark work at the moment, so if you want to step up and make this your contribution, feel free to do so! Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
