dm-timestamps causes major (100x in this example) slowdowns when creating multiple children at once
Reported by Greg Campbell | December 16th, 2009 @ 12:08 PM
In the script at http://gist.github.com/258013, requiring dm-timestamps reproducibly causes the operation to run over 100 times times slower, even if there are no timestamp properties used. Furthermore, adding timestamp properties worsens the problem, as the parent and grandparent node will be re-saved for every child saved in the list. I believe the problem to be the following:
- for each child node saved, save_parents is called
- this triggers dm-timestamps' set_timestamps_on_save method
- set_timestamps_on_save returns unless dirty? is true. dirty? recursively calls dirty_parents? and dirty_children?, and will be true until all children have been saved, as I understand it
One solution would be to check dirty_self? rather than dirty?, but that's api private at this point.
Comments and changes to this ticket
-
Greg Campbell December 16th, 2009 @ 12:08 PM
- Tag set to “dm-timestamps, performance”
-
Martin Gamsjaeger (snusnu) December 16th, 2009 @ 12:34 PM
- State changed from “new” to “confirmed”
-
Greg Campbell December 16th, 2009 @ 12:46 PM
- Tag changed from “dm-timestamps, performance” to “dm-timestamps, performance, regression”
Tagging this as a regression. Although it doesn't technically break functionality, it can make certain previously-supported operations unusably slow. dkubb, please remove the tag if you find it inappropriate, of course.
-
Carl Porth January 12th, 2010 @ 05:22 PM
- Tag changed from “dm-timestamps, performance, regression” to “dm-timestamps, patch, performance, regression”
I think you can get the desired behavior by examining dirty_attributes which is semipublic. Tiny patch included.
-
Dan Kubb (dkubb) February 2nd, 2010 @ 02:25 AM
The reason this is happening is that when saving an object graph due to circular dependencies, the object's save method may be called more than once.
I've fixed this problem by adding a guard clause to Resource#save_self that returns if the object isn't dirty. This also allows me to remove up some logic from create and update that was short circuiting if the object wasn't dirty.
Will push a commit once I've verified the specs pass with every adapter.
-
Dan Kubb (dkubb) February 2nd, 2010 @ 02:42 AM
- State changed from “confirmed” to “accepted”
- Assigned user set to “Dan Kubb (dkubb)”
-
Dan Kubb (dkubb) February 2nd, 2010 @ 03:03 AM
- State changed from “accepted” to “resolved”
(from [1b7669379b79e7e85be9d6d523f2777b5da0c803]) Skip saving if the dirty test returns false
- This will speed up any cases where the resource is being saved and there are before(:save) or after(:save) filters.
- Removed now redundant code from create and update
[#1155 state:resolved] http://github.com/datamapper/dm-core/commit/1b7669379b79e7e85be9d6d...
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
People watching this ticket
Carl Porth
Dan Kubb (dkubb)
Martin Gamsjaeger (snusnu)
Ryan Carver
Attachments
Referenced by
-
1154
Excessive validation when creating multiple children at once
See ticket #1155 for the related dm-timestamps issue.
-
1154
Excessive validation when creating multiple children at once
Tagging this as a regression - see ticket #1155 for
the j...
-
1155
dm-timestamps causes major (100x in this example) slowdowns when creating multiple children at once
[#1155 state:resolved]
http://github.com/datamapper/dm-c...
-
1154
Excessive validation when creating multiple children at once
martinemde's issue is resolved with the fix to #1155.