On Fri, Apr 26, 2013 at 8:47 PM, Claudio Freire <klaussfre...@gmail.com> wrote: > On Fri, Apr 26, 2013 at 8:15 PM, Michael Bayer <mike...@zzzcomputing.com> > wrote: >> >>> Anyway, with that (fragile) change, I get a speedup of 10% overall >>> runtime, and about 50% alchemy-specific runtime. Considering I knew >>> about attribute access' slowness and avoided it in my test, that has >>> to account for something worth looking into? >> >> All attributes have to be expire-able and act as proxies for a database >> connection so I'm not really sure where to go with that. I'm not too >> thrilled about proposals to build in various "alternate performance" >> behaviors as the library starts to try to act in many different ways that >> the vast majority of users aren't even aware of, it increases complexity >> internally, produces vast amounts of new use cases to test and maintain, >> etc. I'm always willing to look at patches that are all winning, of >> course, so if you have some way to speed things up without breaking usage >> contracts and without major new complexity/brittleness I'd love to look at a >> pull request. > > I know, it's just a probe to see what kind of a speedup could be > obtained by not having that getter's interference. You know... simply > implementing InstrumentedAttribute in C could do the trick...
In fact... I'm gonna try that... -- 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.
