On Apr 30, 2013, at 6:26 PM, Claudio Freire <klaussfre...@gmail.com> wrote:
> On Fri, Apr 26, 2013 at 9:09 PM, Claudio Freire <klaussfre...@gmail.com> > wrote: >> On Fri, Apr 26, 2013 at 9:01 PM, Michael Bayer <mike...@zzzcomputing.com> >> wrote: >>>>>>> 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... >>>> >>>> feel free! though you might be surprised, a C function that just calls >>>> out to all the same Python operations anyway is often only negligibly >>>> faster, not enough to make the extra complexity worth it. >>> >>> also if you're looking to help with C, I'd love to get the C extensions out >>> in the Py3K version, we have a patch that's fallen out of date at >>> http://www.sqlalchemy.org/trac/ticket/2161 that needs freshening up and >>> testing. >> >> Will look into that. The point of the C function is to be able to >> quickly bypass all that _supports_population and function call >> overheads. The getter is dead-simple, so its cost is dominated by >> CPython function call overheads, that are readily removable by >> re-implementing in C. It can reliably and quickly detect when >> instance_dict returns __dict__, too. > > Alright, I've got a POC C extension working (gotta profile it yet), > although SQLAlchemy's weird injection of instance_dict forced me to > some ugly hacks: > > > class InstrumentedAttribute(QueryableAttribute): > """Class bound instrumented attribute which adds descriptor methods.""" > > def __set__(self, instance, value): > self.impl.set(instance_state(instance), > instance_dict(instance), value, None) > > def __delete__(self, instance): > self.impl.delete(instance_state(instance), instance_dict(instance)) > > try: > from sqlalchemy.cinstrumented import InstrumentedGetter > __get__ = InstrumentedGetter(globals()) > __get__.__name__ = '__get__' > del InstrumentedGetter > except ImportError: > def __get__(self, instance, owner): > if instance is None: > return self > > dict_ = instance_dict(instance) > if self._supports_population and self.key in dict_: > return dict_[self.key] > else: > return self.impl.get(instance_state(instance),dict_) > > Thing is, doing the whole class in C makes no sense for set and > delete, but it also complicates linking its instance_dict and > instance_state to SA.attribute's. > > This way looks ugly, but it reacts immediately to changing those > globals, so it does seem like the better option. > > Opinions (while I profile)? I'd want to see the whole thing, like what's up with that globals() call, etc. The instance_dict is shuttled around everywhere so that we aren't constantly pulling it from the given object; we have a system in place whereby the fact that instance_dict is object.__dict__ is not necessarily a given, and you can actually use some other system of getting at __dict__. It saved us on a huge number of function calls at some point to expand it out like that, as inconvenient as it is. -- 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.
