Performance regression in 1.0.0

[Paul Dlug]

I recently upgraded from 0.10.1 to 1.0.0 (I believe I had this issue
an an attempted upgrade to 0.10.2 as well). The situation I'm seeing
is that in a many to one relationship there are now n queries for each
of the relationship members where previously there was just one. This
is resulting in some serious performance impact over 0.10.1, I believe
this 'TODO' note in dm-core/associations/many_to_one.rb summarizes
what I'm seeing:

# TODO: lookup the resource in the Identity Map, and make sure
# it matches the query criteria, otherwise perform the query

Is there a fix on the horizon? Any quick and dirty hack I can use to
get around this in the interim? My relationships are all relating the
models to each other using their primary keys, I would think it would
be easy to make this work with the identity map since they would exist
already by PK.


Thanks,
Paul

[Dan Kubb (dkubb)]

Paul,

> Is there a fix on the horizon?

We take performance regressions fairly seriously. If you're seeing a
problem I can look at it this week, and hopefully get a fix before the
1.0.1 release in the next week or so.

> Any quick and dirty hack I can use to get around this in the interim?

Nothing that immediately comes to mind, but I'll let you know.

> My relationships are all relating the
> models to each other using their primary keys, I would think it would
> be easy to make this work with the identity map since they would exist
> already by PK.

First thing though, can you create a ticket to track this issue:

http://datamapper.lighthouseapp.com/projects/20609-datamapper/tickets/new

The next thing I would ask is a small stand-alone script that
demonstrates the problem, with perhaps some comments on your expected
behaviour. This makes sure that I can see what you're seeing. Without
it, I might end up spending alot of time looking for nonexistent
problems in other parts of the system.

Another benefit is that I can use the script to create a spec to
ensure the regression never happens again. Also sometimes when I'm
doing a code spike to figure out how to approach a fix I'll use the
stand-alone scripts to get feedback on whether or not I'm on the right
track.. then I revert the spike, write a real failing spec, and fix
the problem properly.

--

Thanks,

Dan