Re: Django performance vs others

471 views
Skip to first unread message

Amirouche Boubekki

unread,
Oct 5, 2012, 9:24:31 AM10/5/12
to django...@googlegroups.com
I have had no idea until recently that django template are sooo slow... other engines do the same... but spent less time. What the cool feature prevent it for rendering it faster?

The template parsing I guess, but I'm not sure.

Kurtis Mullins

unread,
Oct 5, 2012, 11:13:07 AM10/5/12
to django...@googlegroups.com
Probably the ability to both extend and include (template inheritance)

On Fri, Oct 5, 2012 at 9:24 AM, Amirouche Boubekki <amirouche...@gmail.com> wrote:
I have had no idea until recently that django template are sooo slow... other engines do the same... but spent less time. What the cool feature prevent it for rendering it faster?

The template parsing I guess, but I'm not sure.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Amirouche Boubekki

unread,
Oct 6, 2012, 8:01:58 PM10/6/12
to django...@googlegroups.com, Stanislas Guerra, moonligh...@yahoo.com
Héllo again,


I was going to send the message in django-users then python-list then I though it wasn't good idea... If you think otherwise feel free to FW the discussion to the relevant list.


First, sorry Stan for have been rude and using a rude language with you.

What is wrong with hello world application if you are testing web application stack?

I Moonlight (or maybe Andriy ?). Some thoughts :
  1. Don't be directly involved in a product you are benchmarking against. that's bad
There is no independant consultant that would do this for free on a software that enters the market with no contracts in sight, especially if his or her products is not the best. I think that the benchmarks being opensource are reproducables, so the results are real, even if they might not be relevant, whatever the guy who does them.
 
  1. Make a relevant bench for the conclusion you are claiming. Print "Hello world" is not a benchmark to say a framework is faster than another one. Look at graphical card benchs. They don't display just a rotating cube at very low resolution with 4 colors
I'm not into 3D Graphics that much, but
  1. It involves a lot of back and forth between user code and the graphic card, which involves several level of cachings with complex algorithms, this is not relevant to Web dev 
  2. Maybe jit optimisation or any code optimisation which are only relevant on heavy programs, which is only relevant to heavy computation, hence not relevant to Web dev per se, since if you do a celery call, this is the same call on every Python Web framework
  1. Be scientifically rigorous. Every framework make stuff under the hood when you initialize a project that you can't disregard because the impact is high. Stacks and hooks (auth, session, localization) that can be tuned (or not) in your project settings for instance. So the same "Hello World" (which is only the tip of the iceberg) can run 100 times faster according to your settings.
Raw speed of a vanilla project is also interesting, if tuning will get a program to better performance, then both frameworks will improve with tuning, which might not change the winner. Getting best performance on vanilla project is what every project should look for if it doesn't involve insane settings, fsync=off, Caching every page 1 hour isn't a sane default, using request bound transactions might be etc...
 
The problem with Hello World is that it is way too simple, an insignificant parameter in the numerous/heterogenous/significant other parameters.

Let's start the discussion for real about benchmarking Web frameworks and build a list of the different configurations we need to tests to make it relevant:

- Render a plain template (done)
- Render a cached template 
- Render a template with a cached body response 
- Render a template with constants provided by the view
- Render a cached template with constants provided by the view
- Render a template with constants provided by the view with cached body response
- Render a template with data from a database query (any query will do the job, we are testing the ORM)
- Render a cached template with data from a database query
- Render a template with a cached query against a database
- Render a cached template with a cached query against a database
- Render a template with a query database with a cached body response

I think some of this tests are identical.

Tell me if this tests are relevant and if you know any others ? 

 
I do not say that this bench is absolutely useless. It can be used to show a regression, a bug, test the Apache stack.
Not to make framework comparisons. 

Of course it is, getting used to a new API is possible, it's an investment of scale compared to pay more that what you would pay with an equivalent feature-wise framework, that you will pay forever if you continue to use the same framework.
 

 
Choosing framework X over Y doesn't guarantee any success to project. Good thing to know your framework has a limit... that also tells me how effective one or other implemented... I guess it tells that.


I have had no idea until recently that django template are sooo slow... other engines do the same... but spent less time. What the cool feature prevent it for rendering it faster?

I think this is not a scoop that Django template engine is not the fastest and you are free to use another one.
But I would like to say, if you are in a serious business, don't give a fuck. This is the last reason to fail a real-life project and a pretty low-benefit optimization.
Ok, this is important, but don't over-estimate it.

True, most of the time you get the project out as fast as possible, the client pay the periodic fees including power consumtion fees that might have been avoided with a more efficient solution. But you are still right, maybe given a team, working with a certain framework is more interesting because they can use their knowledge and/or application available in the market to build a good enough solution in time.
 

By the way, I had the curiosity to take a look at Python ML entry which is called "Fastest web framework" and I the Wheezy framework. The cache api - for instance - is not something I would call well designed and useable :


@response_cache(none_cache_profile)
def change_price(request):
    ...
    with cache_factory() as cache
        dependency = CacheDependency('list_of_goods')
        dependency.delete(cache)
    return response

Is it working code ? where does the returned response come from and how does the 3 lines above can impact it ?
If you want to turn off the cache you have to change all that logical code, not just the @decorator, right ? Seriously, dude.

I'm not into cache management particularly and did not read the relevant doc but it seem to me that this is rather a fine-grained cache, and load/unloading of cache context... similarly Django does db dispatching https://docs.djangoproject.com/en/dev/topics/cache/?from=olddocs#database-caching-and-multiple-databases

Regards,


Amirouche

Moonlight

unread,
Oct 10, 2012, 2:59:38 AM10/10/12
to django...@googlegroups.com
I have checked django code used in this post. It is not parsing... just render, here is django template:

<table>
    {% for row in table %}
    <tr>
        {% for key, value in row.items %}
        <td>{{ key }}</td><td>{{ value }}</td>
        {% endfor %}
    </tr>
    {% endfor %}
</table>

It renders a thousand rows and few columns.

Amirouche Boubekki

unread,
Oct 10, 2012, 9:07:04 AM10/10/12
to django...@googlegroups.com, moonligh...@yahoo.com
2012/10/10 Moonlight <moonligh...@yahoo.com>
I think this one explains how it works.

A quick read make me think it's a bit complex.


If this is legit tests, they are impressive. 

Would you mind at least using the django...@googlegroups.com ML...

Thanks,

Amirouche

thanos

unread,
Oct 10, 2012, 8:26:06 PM10/10/12
to django...@googlegroups.com


For real performance I suggest taking a big breath and looking at ChicagoBoss. It's a move I've done that has saved me a lot of money on AWS.

--
You received this message because you are subscribed to the Google Groups "Django users" group.

Moonlight

unread,
Oct 11, 2012, 8:17:08 AM10/11/12
to django...@googlegroups.com, moonligh...@yahoo.com
I think the URL dispatch cases are valid (dynamic urls and some that never changes)... so legit at least for django (I looked at code)... I have no idea if the code is valid for other frameworks. I have run that benchmark as it explained in that post and got almost the same results... hmmm, why 'missing' test case is so slow... even in bottle? Can someone tell me?
Reply all
Reply to author
Forward
0 new messages