On Fri, Apr 26, 2013 at 1:35 PM, Michael Bayer <mike...@zzzcomputing.com> wrote:
>>
>> Um... a tad OT, but looking at that code, there's lots of
>> opportunities for optimization.
>>
>> I'll have to profile a bit and let you know.
>
> are you referring to sqlalchemy/orm/loading.py ? I'd be pretty impressed if
> you can find significant optimizations there which don't break usage
> contracts. I've spent years poring over profiles and squeezing every
> function call possible out of that system, sometimes producing entirely new
> approaches that I just had to throw out since they didn't work. It has been
> rewritten many times. Some background on the approach is at
> http://www.aosabook.org/en/sqlalchemy.html, "20.7. Query and Loading
> Behavior".
I know... I'm talking micro-optimization. Pre-binding globals in tight
loops, for instance, like:
def filter_fn(x, tuple=tuple, zip=zip):
return tuple(...)
This is of course only worth it for really really hot loops. That's
why I'm profiling. Maybe it's been done already for all the hottest
loops.
Then there's the possibility to replace some list comprehensions with
itertools, which besides not building a temp list, would also run
entirely in C. This also only makes a difference only on very tight,
builtin-laden loops.
I have an app here that really stresses that part of the ORM, so I can
profile rather easily. In previous profiles, I remember seeing
Query.instances near the top, and all the optimizations I mentioned
above could be applied there, if they make any difference I'll tell.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
