> > orm.util.AliasedClauses._create_row_adapter() > > class AliasedRowAdapter( object): > > 1. can't this be made as standalone class, returning an > > instance, initialized with the map, which is then __call__()ed ? > > is it faster to say "self.map" or to say "map" from locals() ? its > probably not very crucial either way. well.. u save on class' creation :-), get a class that "could be used elsewhere", and eventualy more obvious code - runtime outer-namespace bindings in python are veeery strange beasts sometimes, with funny side effects.
> > 2. this can be faster if: > > a) has_key = __contains__ #instead of yet another funccall > > b) __getitem__ uses try except instead of double lookup key > > in map > > im not sure try/except is faster here - im pretty sure a missing > key is likely and exception throws are very expensive. would be > worth a try to see if the missing key exception actually occurs > here. i'll have to check, last 3 years i've being doing everything assuming that a (lookup:exception) is faster than (lookup-if-lookup:lookup-else) in both attribute and dict lookups. Plus that a function call is the most expensive python thing ever... apart of repeated a.x a.x a.x attribute access. hmmmm time to measure the myths. > > ------- > > orm.attribute > > AttributeManager.init_attr(): > > the saving this one eventualy does is too small, compared to > > a property call of ._state. > > i havent benched this in a while but my recollection is that the > AttributeError raise is *much* slower than pre-calling this method. > a single function call is always faster than an exception throw. > > however, i see that the exception throw is being suppressed also > with a hasattr() being called every time....im not sure why thats > that way now so i might change it back to throwing AttributeError. > > > btw: cant that ._state property be removed alltogether (i.e. > > made a plain attribute? then init_attr() MUST be there seting it > > up as plain dict. > > it should be named something non-collisionworthy such as the > current _sa_attr_state. the only gain from the property is that it is readonly, i.e. obj._state = None is not allowed (as well as del'ete). But i can do obj._sa_attr_state = None (and all goes to hell). If that property disappears alltogether, we are left with a plain _sa_attr_state attribute, which can be now set to None and deleted... which is more or less same as before less the complications with the property. Fair trade, no? > > ------- > > util: > > ThreadLocal: > > - wouldnt be faster if the key in the _tdict is tuple(id,key) > > and not some formatted string off these? or the key is > > nonhashable? > > good catch, should be patched > > > - the engine/threadlocal.TLEngine._session() issues a > > hasattr() on such object. how does it actualy work? IMO it always > > fails > > patch which includes a test case to add into test/engine/ > transaction.py would be welcome i've never used these so no much idea what to do here - was just passing code along my eyeline. will prepare some patches for the other things. ciao svilen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
