Trevor Squires wrote:
> 1 - using :include one-level-deep when you are fetching *one*
> toplevel object *and* you are not issuing :conditions on
> the :included tables is *always* (well, I've never found an
> exception) slower.
>
> x = Foo.find(4678. :include => [:incoming_messages, :outgoing_messages])
>
> is slower than:
>
> x = Foo.find(4678)
> x.incoming_messages
> x.outgoing_messages
>
> If your reaction is to say "but it's always faster with eager
> loading" then I urge you to *measure* it and get back to me if you
> find that my measurements are wrong.
I'm surprised the effect of the extra data and data processing
that comes with use of :include so clearly trumps the chained
latency of the extra database calls.
Do you think you would get the same result when:
1. The database is on another server,
2. :select is used to restrict the size of base model data returned, and
3. Hashes are used to speed matching in the construction of the object
hierarchy, like in Fred's patch?
Jeremy's n+1 solution obviously becomes more attractive as the include
chain gets longer and the records larger. But there would still be a
switchover point that's a function of database comms latency. Such a
solution would really be aided by sending the database commands in parallel.
--
We develop, watch us RoR, in numbers too big to ignore.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
