Eager loading optimization patch

[Pratik]

Hi,

I've uploaded a patch to optimize eager loading, which changes the
code to spend less time in ruby -
http://dev.rubyonrails.org/ticket/10011

The problem is because of following line in
associations.rb:#construct_associations :
collection.target.push(association) unless
collection.target.include?(association)

This basically compares every processed object with the new object, to
see if it hasn't been instansiated already.

For testing, I created two simple models :

class Person < ActiveRecord::Base
has_many :items
end

class Item < ActiveRecord::Base
belongs_to :person
end

Data : 1 Person and 1000 items belonging to that person.
Performance Script : http://pastie.caboo.se/111774
Before the patch : http://m.onkey.org/before.html
After the patch : http://m.onkey.org/after.html

Please test the patch if you can and also post your comments/suggestions.
--
Cheers!
- Pratik
http://m.onkey.org

[Tarmo Tänav]

Looks interesting.

I don't have time to test this but have you tried to eager load several
has_many associations at once (so there are M*N result rows)
and compare the memory consumption of the new approach with the old one?

[Mark Reginald James]

Pratik wrote:

> I've uploaded a patch to optimize eager loading, which changes the
> code to spend less time in ruby -
> http://dev.rubyonrails.org/ticket/10011
>
> The problem is because of following line in
> associations.rb:#construct_associations :
> collection.target.push(association) unless
> collection.target.include?(association)
>
> This basically compares every processed object with the new object, to
> see if it hasn't been instansiated already.

How does this compare to Fred Cheung's patch?

http://groups.google.com/group/rubyonrails-core/msg/b4da8cedcd73eaae

--
We develop, watch us RoR, in numbers too big to ignore.

[Frederick Cheung]

That was rather fugly :-) Array#uniq! basically builds up a hash and
then collects the things in the hash, so it should be pretty similar.
The one possible area of concern (as pointed out by tarmo) is memory
consumption with a large result set.

Fredd