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 -~----------~----~----~----~------~----~------~--~---
