I’ve casually glanced through rails’ code and it seems pretty legit.
Not too inefficient. Does what it should.
So…my question is…why is it still somewhat slow? Blame it on Ruby,
I suppose, however, there have been reports that running rails on Ruby
1.9 only results in a 15% increase–which is somewhat disappointing.
So…how could one best contribute to try to get rails faster?
Or stated in other words: where’s the bottleneck? Just the VM?
Do Ramaze or merb run very large sites much faster? If so then rails
might be the culprit.
If not then I guess it’s just a ruby thing[?]
Thanks!
-R
The easy “copout” answer to questions of why Rails is slow is to blame
Ruby. Is Ruby slower than other languages, sure it is. But, this is
not the interesting question. The interesting question is, “How much
does Ruby performance matter to your application?”
Is it really that important to reduce your Ruby execution time from
say 100 milliseconds to 80 milliseconds so that you can gain more time
to wait 1000 milliseconds for the database to return your result set?
My point is that there are multitudes of factors involved in system
performance. Each part needs its own optimization. It’s so easy to
look at a set of benchmarks and draw conclusions about how platform x
is y times slower than platform z. However, that doesn’t take into
account any other platform advantages. For instance, it says nothing
about developer productivity. How much more performance do you get out
of that Rails application you built and deployed over the weekend,
while you’re still waiting for a Java team to get the project out of
the initial planning stage?
I realize these may be exaggerated examples, but as a JavaEE developer
by trade, just learning Rails, this is what has attracted me to the
Rails framework. I personally find that, on average, I can produce
between 4 and 5 times more deployable program features given a fixed
block of time. And I find the Rails code to be much easier to
understand, maintain, and enhance. So the developer productivity is
sustainable though the life of the product. In the vast majority of
cases this far outweighs the fact that Ruby is somewhat slower than
other languages.
Nearly every performance problem I have encountered has nothing to do
with the processor performance anyway. It’s nearly always some poor
database design (or usage) that causes the problem. And with a 4 to 5
times increase in deployable code, and shorten release cycles, it’s
usually pretty easy to budget in an extra Linux box to make up the
performance difference.
def choose_language
if scaleability == language_performance
development_language = assembly
else
development_language = your_choice
end
end
protected
def your_choice
what_makes_you_productive_and_happy
end
On Apr 29, 6:44 pm, Roger P. [email protected]
I advice you to do it :
[1] dont put prototype.js to your layout if it’s useless, because it
will verify each time you’re loading the page.
[2] use restful to speed up your performance.
[3] Decrease in using tons of plugins.
[4] Optimize uses of ActiveRecord. All activities of ActiveRecord should
put it in ActiveRecord, dont in controller or View. And all business
logics of controller dont runt it in View.
[5] Decrease in storing your image in database.
[6] Dont repeat your self in controller.
[7] If you use AJAX, package it, if not it will make your web so slow.
[8] Compress your image.
[9] Checkout your webserver, you can contact your support to analyze
your webserver or bandwith.
Good Luck,
reinhart
http://teapoci.blogspot.com
Experts Advice :
http://www.bencurtis.com/archives/2007/08/5-tips-to-speed-up-your-rails-app/
http://www.clipclip.org/clips/detail/6487/infoq-a-look-at-common-performance-problems-in-rails
http://www.fak3r.com/2006/05/11/speed-up-ruby-on-rails-with-memcached/
On 30 Apr 2008, at 22:46, Bob P. wrote:
with Rails being slower than other frameworks. It is why Rails needs
to have a pre-running engine running with a pre-loaded version of
ActiveRecord.
I’m not sure what you mean - ActiveRecord (along with all of rails
itself) is loaded when the server is started.
Fred
Frederick C. wrote:
to have a pre-running engine running with a pre-loaded version of
ActiveRecord.
I’m not sure what you mean - ActiveRecord (along with all of rails
itself) is loaded when the server is started.
It all comes down to what part of the performance is a concern. Roger
the original poster didn’t say and frankly I just made assumptions.
I was probably wrong.
Loading is the only performance issue I see. Once it is loaded I
don’t have any performance concerns. Therefore by that logical case
that I kept private in my own head I assumed Roger was concerned about
load time performance.
Bob
Roger P. wrote:
So…my question is…why is it still somewhat slow? Blame it on Ruby,
I suppose, however, there have been reports that running rails on Ruby
1.9 only results in a 15% increase–which is somewhat disappointing.
My testing show me that the slowest part of Rails is loading all of
the ActiveRecord components. AFAICT this is the fundamental issue
with Rails being slower than other frameworks. It is why Rails needs
to have a pre-running engine running with a pre-loaded version of
ActiveRecord.
Of course on the other hand many people feel that ActiveRecord is one
of the best parts of Rails and therefore feel that the performance
penalty is well worth it for the gain in functionality.
So…how could one best contribute to try to get rails faster?
Optimize AciveRecord and it would speed up Rails.
Or stated in other words: where’s the bottleneck? Just the VM?
The Ruby interpreter is slower than other interpreters but not unduly.
This is getting speeded up in newer Ruby versions. But performance is
on the same order of magnitude as other interpreters. But it doesn’t
account for the ActiveRecord load times. If another language were
used with the same design I am sure the same performance issues would
be noted.
Bob
generally speaking, I didn’t feel ruby-on-rails is slower than struts-
(or spring)-on-Java.
J2EE is the worst performer I ever seen, but it still hold big chunk
of the enterprise market.
roosevelt
www.radio21g.com
On Apr 30, 6:44 am, Roger P. [email protected]
[email protected] wrote:
generally speaking, I didn’t feel ruby-on-rails is slower than struts-
(or spring)-on-Java.
J2EE is the worst performer I ever seen, but it still hold big chunk
of the enterprise market.
When you run it in production mode, you will feel it slower than php in
apache. but java is still the slowest. Since i knew and learn Java, Yet
no one project was done in Java, always ruby on rails or Cakephp.
reinhart
http://teapoci.blogspot.com
On May 1, 7:22 am, Visit Indonesia 2008 <rails-mailing-l…@andreas-
s.net> wrote:
[email protected] wrote:
generally speaking, I didn’t feel ruby-on-rails is slower than struts-
(or spring)-on-Java.
J2EE is the worst performer I ever seen, but it still hold big chunk
of the enterprise market.
When you run it in production mode, you will feel it slower than php in
apache. but java is still the slowest. Since i knew and learn Java, Yet
no one project was done in Java, always ruby on rails or Cakephp.
When it comes to raw performance, Java is without hint of doubt much
faster than ruby (how else could jruby be faster than ruby 1.8). Of
course you can write a slow application in java, but you can do that
in rails too.
Fred
Thanks for all your help guys.
Looks like to speed up loading there are a few options
[http://pennysmalls.com/ describes a few]. I’ll see if they help
much. I wonder if once AR is loaded ‘quickly’ uses these plugins if
1.9 ‘really speeds up’ rendering or what not. That would be a sweet
thing.
-R
I have made a lot of tests myself, and the slowness of Rails comes from:
- InnoDB engine when performing loads of SELECT.
- ActiveRecord which by default does a SELECT *
- ActiveRecord which creates objects from everything returned from DB.
- using :include with AR
- using view helpers such as link_to and that kind of crap
- coding practices from former php coders
- plugins that do too much introspection like permalink_fu which can be
hardcoced in only 3 lines in the model.
- people forgetting about caching
- …
By refactoring my code very frequently and keeping an eye on what SQL
queries AR creates, I can increase my app’s performance by x5 on some
critical processing. My biggest increase was actually x1000 by working
on tuning the DB with a very big table of 100k rows.
Honestly I consider that Rails is fast, it is the coder who doesn’t know
how to use it correctly that is the real problem.
Yet no vendors or programing languages have claimed that they are faster
or fastest. Every application can be slower or faster even slowest or
fastest, depend on programmer or system analyst who work together
composing or creating its application. 
Reinhart
On Sep 16, 11:59 pm, Roger P. [email protected]
wrote:
By refactoring my code very frequently and keeping an eye on what SQL
queries AR creates, I can increase my app’s performance by x5 on some
critical processing. My biggest increase was actually x1000 by working
on tuning the DB with a very big table of 100k rows.
Interesting, so it’s AR loading that was troublesome.
Well with the release of 2.2 and some non blocking IO drivers [4]
hopefully it will put some more focus on speed, since there will no
longer be an excuse of “well all the latency is caused by IO” I hope 
Most of the time, the significant overhead is with AR composing the
resultset into AR objects. Most benchmarks I saw report small times on
the DB side (even with large resultsets). Of course, the smaller the
resultset, the less objects AR has to compose so it’s always a good
idea to watch the SQL.
Fernando P. wrote:
I have made a lot of tests myself, and the slowness of Rails comes from:
…
- ActiveRecord which creates objects from everything returned from DB.
I did notice a plugin which attempts to combat this–slim_attributes [1]
and also hash_extension [3]
No help there
- using view helpers such as link_to and that kind of crap
Recently found one treating this subject, as well [though it’s may not
be that polished] [2].
- coding practices from former php coders
- plugins that do too much introspection like permalink_fu which can be
hardcoced in only 3 lines in the model.
- people forgetting about caching
- …
By refactoring my code very frequently and keeping an eye on what SQL
queries AR creates, I can increase my app’s performance by x5 on some
critical processing. My biggest increase was actually x1000 by working
on tuning the DB with a very big table of 100k rows.
Interesting, so it’s AR loading that was troublesome.
Well with the release of 2.2 and some non blocking IO drivers [4]
hopefully it will put some more focus on speed, since there will no
longer be an excuse of “well all the latency is caused by IO” I hope
Thanks all!
-=R
[1] http://pennysmalls.com/2008/04/02/speed-up-mysql-in-rails/
[2]
Rails Template Optimizer Beta Test
[3]
http://blog.chak.org/2008/01/22/activerecord-is-slow-hashes-are-fast/#comment-81
[4]
MySQLPlus: A Non-Blocking MySQL Driver for Ruby 1.8 and 1.9