On Apr 26, 2013, at 6:13 PM, Claudio Freire <klaussfre...@gmail.com> wrote:
> Ultimately, though, it's InstrumentedAttribute.__get__ the one sucking
> up 30% of alchemy-bound CPU time. I guess there's little that can be
> done, since it's necessary to track state changes. But there's a neat
> property of descriptors, where if they don't implement __get__, then
> they don't take precedence over the instance's dict.
>
> This is very interesting, and handy, since when instance_dict is
> attrgetter('__dict__'), then, for regular ColumnPropertys, instead of
> using InstrumentedAttribute, I can replace that with an
> "InstrumentedWriteAttribute" that has no get. This means, all of a
> sudden, no overhead for simple attribute access.
>
> I've tested it and it mostly works. There's the "instance_dict is
> attrgetter('__dict__')" thing hanging over my head, and the more
> serious issue of lazy attributes being mostly broken, but it's an
> interesting POC IMHO.
just to be clear, you're breaking the capability of column-based attributes to
lazy load at all, right? Yeah, that can't really fly :). The whole object is
a live proxy for a database row, we have "deferred", all kinds of stuff.
We have had users work on alternative "static object loading" routines, but of
course the Query can return cheap NamedTuples to you if you just want fast
immutable columns.
> 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.
> (before optimizing for
> attribute access slowness, the test was about 3 times slower IIRC -
> *times* - and it does a hefty amount of regex processing beyond
> handling attributes)
Im not sure what regexes you're referring to here.
--
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.
