On Apr 13, 2011, at 10:05 PM, Chung wrote: > > 1. Query compilation... This > > resulted in ~2x improvement. > > that seems very strange - 2x improvement in....the overall speed of your > application? I've done an enormous amount of profiling - SQL compilation is > miniscule compared to the SQL statement's execution itself and the fetching > of rows. > > This is because our workload mostly consists of a ton of Query.get() calls, > where the actual SQL execution/row fetching is very fast. That's probably > why we're even noticing all this overhead that would normally be > insignificant :-)
sometimes with a heavy get() type of situation, if you can pre-load your Session with the things you're going to be getting, then you just have a small group of queries up front. The get() calls then pull from identity map: s = Session() # store the range of objects you're dealing with in lists. the strong # reference ensures they stay present in the Session class_a = s.query(ClassA).filter(ClassA.some_column.between(....some range...)).all() class_b = ... <similar> # now do lots of gets against s: s.query(ClassA).get(x) s.query(ClassB).get(y) # .... # when done ! make sure the collections fall out of scope or del them del class_a del class_b # and if you're really done you can do this too s.close() I do this a lot when doing large batch jobs where there's lots of many-to-one relationships to a limited set of objects shared by many parents (like a user linked to a Country, for example). many-to-one get() fetches from the identity map are also way faster in 0.7 - we cut down a big heap of overhead that wasn't necessary. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
