Speed test between Rails (1.1.6 and 1.2.1), Django (w/wo psyco and
threaded/pre-forked), TurboGears, Symfony, Catalyst etc. Nginx as the
front-end for all of them.
Even though they are simulated numbers I thought it might be
interesting to discuss. Besides the fact that from these tests Django
seems to be whooping serious butt on all fronts, it shows that Rails
1.2.1 seems to be trailing in performance (quite a bit in some places)
in comparison to 1.1.6. Anyone seen the same thing in a production
site?
I'm curious if there is anything significantly missing in these tests
and how Django got such great numbers (Or maybe it is just that
efficient? I have no real Python/Django experience.). Thoughts?
But there's a reason for that, and I bring it up here in the hope of
fostering a good discussion rather than simply "rah-rahing" Django,
the Python framework that I'm involved in developing.
We made fundamental decisions in Django that eschewed magic in favor
of a bit more explicitness. Plus, performance was baked into the
framework from Day One, rather than us taking a "we'll make it
efficient later" stance. As a result, Django doesn't have to do as
many things dynamically as Rails does.
The tradeoff is that, in Django, you'll have to use an import
statement if you want to use a certain bit of code, rather than the
code magically being available to you. The tradeoff is that, in
Django, you define your database models in Python code rather than
having the framework introspect the database at runtime. Overall, the
tradeoff is that, in Django, you're a tiny bit more explicit.
Of course, this isn't an "I hate my job, this is so tedious" level of
explicitness -- Django is, after all, intended to save you a ton of
time. It's more like a pragmatic level of explicitness. And it has
some nice side benefits, such as the aforementioned performance
benefit (which is important) and the fact that explicit code is more
"discoverable" (i.e., it's easier to poke into the framework to see
what's *actually happening*).
If you give Django a shot, I'm pretty sure these differences will jump
out at you. Whether you appreciate the difference is completely a
personal decision, and no amount of marketing is going to change your
mind. (Well, for most people.) The difference between Rails and Django
programmers seems to be the programmers' tolerance for magic.
Performance is a nice side benefit of less magic.
We made fundamental decisions in Django that eschewed magic in favor
of a bit more explicitness. Plus, performance was baked into the
framework from Day One, rather than us taking a "we'll make it
efficient later" stance. As a result, Django doesn't have to do as
many things dynamically as Rails does.
Have you measured the influence of any of these decisions? It would be
interesting to know what the cost of not being explicit is in various
places.
The tradeoff is that, in Django, you'll have to use an import
statement if you want to use a certain bit of code, rather than the
code magically being available to you. The tradeoff is that, in
Django, you define your database models in Python code rather than
having the framework introspect the database at runtime. Overall, the
tradeoff is that, in Django, you're a tiny bit more explicit.
These are all things that in a Rails app, when run in production
environment, happen just once. I'm not convinced that any of these is a
major factor in Rails performance.
These are all things that in a Rails app, when run in production
environment, happen just once. I'm not convinced that any of these is a
major factor in Rails performance.
I didn't see any db models even used in the speed test. This just
highlights that there are some optimizations to be made in ActionPack.
They should try the same test with merb
