Please sign in to comment.
Replace internal implementation of eager_graph with much faster version
In my testing, this is anywhere from 75% to 225% faster than the previous implementation (which hasn't changed much since its release in Sequel 1.5.0). Before, eager_graph relied on graph_each to split the hash into subhashes and turn each subhash into a model object. However, in many cases (unless you are only eager graphing *_to_one associations), that is wasteful, as many of the instances don't get used. This new approach keeps the plain hash all the way through to the eager_graph stage. It uses the metadata provided by graph to parse the hash into subhashes and create model objects, but only does so if it is needed (i.e. the model object has not been seen before). That's the primary strategic optimization. I have also made numerous micro-optimizations to reduce the number of method calls and hash lookups. Before, the loading was done purely in Dataset methods. Now, there is a new class called EagerGraphLoader that handles the specialized loading. This is backwards compatible except in the case where you call a method other than all on the eager graphed dataset. Previously, you got a hash with table alias keys and model instance values, like you would for a plain graph call. Now, you just get a plain hash. I apologize to anyone relying on the previous behavior, but I think the performance improvement merits breaking backwards compatibility in this case, especially considering how unlikely it is that people are relying on the behavior. There's minor fallout from this change in the sharding plugin, and significant fallout in the identity_map plugin, but this commit includes fixes for the fallout in both cases.
- Loading branch information...
Showing with 386 additions and 159 deletions.
Oops, something went wrong.