Re: Django performance vs others

[Moonlight]

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?

2012/10/10 Moonlight >
>
>> I think this  one 
>> explains how it works.
>
>
> A quick read make me think it's a bit complex.
>
> Check out the routing benchmark too 
> http://mindref.blogspot.fr/2012/10/python-web-routing-benchmark.html
>
> If this is legit tests, they are impressive. 
>
> Would you mind at least using the django...@googlegroups.com 
> ML...
>
> Thanks,
>
> Amirouche
>

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

Re: Django performance vs others

[thanos]

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.

On Wed, Oct 10, 2012 at 9:07 AM, Amirouche Boubekki <
amirouche.boube...@gmail.com> wrote:

> 2012/10/10 Moonlight 
>
>> I think this  one
>> explains how it works.
>
>
> A quick read make me think it's a bit complex.
>
> Check out the routing benchmark too
> http://mindref.blogspot.fr/2012/10/python-web-routing-benchmark.html
>
> If this is legit tests, they are impressive.
>
> Would you mind at least using the django-users@googlegroups.com ML...
>
> Thanks,
>
> Amirouche
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

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

Re: Django performance vs others

[Amirouche Boubekki]

2012/10/10 Moonlight 

> I think this  one
> explains how it works.


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

Check out the routing benchmark too
http://mindref.blogspot.fr/2012/10/python-web-routing-benchmark.html

If this is legit tests, they are impressive.

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

Thanks,

Amirouche

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

Re: Django performance vs others

[Moonlight]

I have checked django 
codeused
 in 
this post. It 
is not parsing... just render, here is django template:

{% for row in table %}{% for key, value in row.items 
%}{{ key }}{{ value }}{% endfor %}   
 {% endfor %}


It renders a thousand rows and few columns.

On Friday, October 5, 2012 3:14:43 PM, Kurtis wrote:
>
> Probably the ability to both extend and include (template inheritance)
>
> On Fri, Oct 5, 2012 at 9:24 AM, Amirouche Boubekki 
> 
> > 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.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/0XK7poV-brwJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django performance vs others

[Amirouche Boubekki]

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 
> scoopthat
>  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

Re: Django performance vs others

[Kurtis Mullins]

Probably the ability to both extend and include (template inheritance)

On Fri, Oct 5, 2012 at 9:24 AM, Amirouche Boubekki <
amirouche.boube...@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-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

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

Re: Django performance vs others

[Amirouche Boubekki]

>
> 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-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.