> do you mean, the compilation of the Select object into a string ? > extremely unlikely. the main speed issue with get() is that of > fetching rows from DBAPI and processing into object results, which > goes up by a huge margin if you have a lot of eagerly loaded > instances attached to the get. the ORM has to create a copy of each > object's attributes in memory in order to track attribute history as > well as perform a lot of other bookkeeping. what youre looking for > is a second-level cache which is currently a RYO (roll-your-own) > feature.
I ran a few get()s with non-existent ids (which are therefore returning no rows, confirmed by setting engine.echo to 'debug'). The average query time was about 80ms, though it varied from 56ms to 110ms. I also called engine.execute with the generated SQL a few times, substituting in different ids. The query time was quite consistently around 17ms. The variation in the time to do get()s seems particularly strange. Thanks, Graham --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
