Slow startup using ruby 1.9.2 vs 1.8.7

There has been an ongoing thread [1] on the RoR talk list about startup time using Rails 3 with Ruby 1.9.2. Do not be confused by the subject of the thread, which mentions 1.9.1, it has moved on to 1.9.2. The gist is that on Ubuntu (and possibly Macs) the startup time when using 1.9.2 can be very much greater then 1.8.7, even with a minimal app. This applies to running tests, migrations, server startup and so on.

Can anyone here throw any light on this?

Thanks in advance

Colin

[1] http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/f3a7e26f8ef528fe

I somewhat mentioned this [1] when I was running ActiveRecord tests under 1.9.2 vs 1.8.7. Someone else mentioned there was a bug fix [2] which I can see is applied to both 3-0-stable/2-3-stable. Even though after this, I still found 1.9.2 to be way slower. I never did the legwork to find out if it was startup time or otherwise.

I just tested a project of mine on rails 3.0.3 under the latest 1.9.2 and 1.8.7 and I can confirm your results from the other thread. I can see boot times and tests taking twice as long under 1.9.2 vs 1.8.7. I too would love to see more investigation and a resolution to this.

[1] http://groups.google.com/group/rubyonrails-core/browse_thread/thread/fb4bbf2cc314d51e [2] #5410 Multiple database queries when chaining named scopes with rails 2.3.8 and ruby 1.9.2 - Ruby on Rails - rails

- Ken

5410 should be fixed…

1.9.2 has this new setup where you can implement a function “responds_to_missing” to deal with responds_to for functions that are handled by method_missing.

ActiveRecord was removing all the default methods on the AssociationProxy object that didn’t match a regular expression - so it was also removing the default implementation of responds_to_misisng. However, 1.9.2. would still attempt to call responds_to_missing and that was being passed on to method_missing.

In the case of 5140, the extra call to method_missing on the AssocaitionCollection didn’t match any of the functions it normally handles so it would end up just calling “super”. AssociationProxy, by design, would load the entire collection from the database and then pass the method on to the actual instantiated collection.

So If you did @author.books.size

.size should have been handled by the AssociationCollection and just generated the select count(*) but before that could happen, method_misisng on AssocationProxy would get trigged - causing the entire collection to load before it would then do the second correct query and return the size of the collection.

5410 should be fixed..

Do you believe that may be the cause of the slow startup using 1.9.2? I believe that Ken Collins said that it made little difference for him.

Colin

Agreed!

Please do not let my aside on 5410 distract the issue. 1.9.2 is still slow!

- Ken

There are things that the C require code does in 1.9 that slow things down. One such example is re-checking $LOAD_PATH to make sure it is all expanded on every require. This is something that should be addressed by ruby-core. I’ll open a ticket on redmine if there isn’t one already.

Yehuda Katz Architect | Strobe (ph) 718.877.1325

ko1 was looking for a sample app to reproduce the problem,

That bug was specific to certain situations, namely calling methods on named scopes or association proxies. There are certainly other fish to fry, I just wanted to address that one specific case.