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<https://groups.google.com/forum/#!topic/django-developers/cQWfKuX5byk>that > Django template engine is not the fastest and you are free > to use another > one.<http://lethain.com/replacing-django-s-template-language-with-jinja2/> > 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 <http://www.codeirony.com/?p=9>. > 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<http://mail.python.org/pipermail/python-list/2012-September/631384.html>which > is called "Fastest web framework" and I the Wheezy > framework <http://pypi.python.org/pypi/wheezy.web/0.1.304>. The cache > api<http://packages.python.org/wheezy.http/userguide.html#content-cache>- 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 -- 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.
