Rails - Jan 2007 - Interesting Framework Speed Test Results. Shows Rails 1.2.1 trailing 1.1.6.

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?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Jan 30, 4:06 am, "Marston A."
<mars...-8Qo2DTIsO68RmelmmXo44Q@public.gmane.org>
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. :-)

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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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 Schuerig
mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org
http://www.schuerig.de/michael/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---