[sqlalchemy] Re: Cascade performance
i doubt this was any faster in previous releases since the basic metholodgy of cascade hasnt changed; when you attach object B to object A, it cascades the save-update operation across the entire graph represented by B. While there was one little fix a while back so that it wouldnt do cascade if B was already in the session, that doesnt address this situation where you are attaching an unsaved instance which contains references to a whole graph of saved instances. so ive added your test with an extra assertion that the session in fact contains 611 instances to the test/perf directory, and added an extra argument to the cascade functions called halt_on which indicates to stop cascading if a condition is met; session sets sends the condition as c in self so that cascading along save/update/save-update will cease along a branch if the instance is detected to be in the session already (i.e. assumes all of its child instances are handled). thats rev 2116 and the results are now: Create forward associations Time to create item 0: 0.07357 sec Time to create item 1: 0.10025 sec Time to create item 2: 0.04157 sec Time to create item 3: 0.06601 sec Time to create item 4: 0.04751 sec Time to create item 5: 0.06988 sec Time to create item 6: 0.03998 sec Time to create item 7: 0.07138 sec Time to create item 8: 0.04332 sec Time to create item 9: 0.07191 sec Created 610 objects in 0.62538 sec Create backward associations Time to create item 0: 0.03061 sec Time to create item 1: 0.05590 sec Time to create item 2: 0.03099 sec Time to create item 3: 0.07053 sec Time to create item 4: 0.04608 sec Time to create item 5: 0.06852 sec Time to create item 6: 0.03841 sec Time to create item 7: 0.07422 sec Time to create item 8: 0.03793 sec Time to create item 9: 0.06976 sec Created 610 objects in 0.52296 sec --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Cascade performance
Michael Bayer wrote: i doubt this was any faster in previous releases since the basic metholodgy of cascade hasnt changed Probably wasn't, I've just been testing with larger data sets lately. so ive added your test with an extra assertion that the session in fact contains 611 instances to the test/perf directory, and added an extra argument to the cascade functions called halt_on which indicates to stop cascading if a condition is met; session sets sends the condition as c in self so that cascading along save/update/save-update will cease along a branch if the instance is detected to be in the session already (i.e. assumes all of its child instances are handled). thats rev 2116 and the results are now: Create forward associations ... Created 610 objects in 0.62538 sec Create backward associations ... Created 610 objects in 0.52296 sec Thanks a million Mike! Works like a charm. It's interesting that it's now (slightly) faster to add them the backward way than it is to add them the forward way. I double-checked the results and I get the same behavior on my machine. Is there more room for optimization maybe? ~ Daniel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Cascade performance
well things like this, i.e. cascade not going over the same field of objects over and over again, are big and obvious. smaller things, its mostly the attributes package that adds the overhead in...i put that package through a huge overhaul some versions ago to simplify it, and i ran it repeatedly through profiling to try to cut it down as much as possible. the key is to remove as much on_set/on_get behavior as possible and move it all to the lets just figure it all out at flush time stage. but for it to be much faster at this point would require a major paradigm shift in how it works. when you look at it, some of what it does might appear wasteful but then, theres usually a unit test that will break if you try to simplify it further. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Cascade performance
Daniel Miller wrote: Lately I've been noticing severe slowness when instantiating new SA objects... Oh yeah, I forgot to mention that many of my class constructors take a parent object as one of their arguments, which explains the slow instantiation. cascade_test.py demonstrates that the problem is not happening during instantiation, but rather when setting the parent attribute on the child object. ~ Daniel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
