Hi Michael, Thanks for the quick reply.
What I am in fact doing is undefer all fields, eagerload all relations (and undefer the corresponding fields) for a corresponding model. (ended up being 9xx options altogether) And yes, I am on 0.3.11 (and probably is unable to move onto a 0.4 as I am relying on an old and custom version of elixir and some custom sqlalchemy fixes), I guess the question is whether it is possible (easy) to rip the benefit of those improvements by merging the 0.4 code into my current 0.3.11? Lei I guess the question now is, On Dec 18, 4:25 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Dec 17, 2007, at 10:38 PM, Esceo wrote: > > > > > Hi, > > > I am just wondering about the traversal order of ClauseVistor, does it > > have to be in a set order? > > > I am eagerloading lots (1000s) of relations, and query compilation > > take a long time, a profiling revealed that most of the time was spent > > in traverse. > > it sounds like you are on an old version of SQLAlchemy as the compiler > does not use any method called "traverse" anymore. If you are on any > 0.4 version, our statement compilation is quite fast; as of 0.4.1 > INSERTs and UPDATEs take around 40-50 function calls and a SELECT > about 120-150 (the callcount goes up with complexity obviously). Also > if you can clarify what "eagerloading 1000s of relations" means, since > i doubt you are issuing a JOIN of 1000 tables, that would be helpful. > If youre on an 0.3 version and switch to 0.4.1 youll see a significant > decrease in processing time for just about everything, and 0.4.2 is > going to improve an average of about 20% over 0.4.1 (available in > trunk if you feel like trying it). > > > So, I am just wondering if the performance will bump up > > if we do not have to use intermediate lists (or use one less list) to > > maintain the traversal order. > > Again assuming 0.4, there's no lists of traversal order used in > statement compilation, it calls each function as needed in order to > render each component of the select, using regular recursive > generation, and the order of function calls is exactly the order of > each component in the final string output. We profile all the time, > in fact on a daily basis, and we are quite fast; if you've seen those > infamous Robert Brewer tests, we actually beat out at least one of the > competitors when the tests are made fair by removing the hundreds of > transaction commits that only the SQLAlchemy test, but not the others, > is made to do. I'm debating doing some more blog posts about that. > > If youre talking about the visitiors.py traversal, thats not used > right now in statement compilation, and the 0.4 version is also an > inlined, non-recursive version which is generally faster than a > recursive algorithm since it incurs very little method call overhead, > which tends to be one of the most expensive things in Python. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
