Interesting Framework Speed Test Results. Shows Rails 1.2.1

I found this little post over at the Slicehost forums (http://
forums.slicehost.com):

http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-
frameworks/

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?

On Jan 30, 4:06 am, “Marston A.” [email protected] wrote:

Besides the fact that from these testsDjango
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 howDjangogot such great numbers (Or maybe it is just that
efficient? I have no realPython/Djangoexperience.). Thoughts?

Django is just that efficient. :slight_smile:

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.

Adrian


Adrian Holovaty
holovaty.com | djangoproject.com

On Tuesday 30 January 2007 17:05, Adrian Holovaty wrote:

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.

Michael


Michael S.
mailto:[email protected]
http://www.schuerig.de/michael/

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 :slight_smile:


Rick O.
http://weblog.techno-weenie.net
http://mephistoblog.com

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs