Le Jeudi 15 Juin 2006 14:14, Emanuele Aina a écrit :
> > Every classes that define the __eq__ operator will find quickly the
> > elements if they are at the beginning of the list.
> > If they are at the end, the in oprerator is slower in these classes
> > because of the overhead of function calls (in StateLt there is also an
> > overhead due to
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> > internal lookup, IMO).
>
> ^^^^^^^^^^^^^^^
>
> Yes, that was my question! :)
>
> But I hoped in a more exaustive answer: why python has to do this
> lookup when the __lt__ method is not involved at all?
Ah, ok sorry, got your point, I didn't notice it in first time.
There is effectively an overhead when the class defines at less one of __lt__,
__gt__, __neq__ ... special attributes (comparison attributes), it seems in
my example that this overhead is a ratio of 1,5x.
It is related to comparison, as the following code show :
import timing
class State(object):
def __init__(self, value):
self.v = value
class StateFoo(State) :
def foo(self) : pass
class StateNew(State) :
def __nonzero__(self) : return None
class StateGT(State) :
def __gt__(self) : return None
class StateGTLT(StateGT) :
def __lt__(self) : return None
def test(cls) :
print cls
inst = cls(5)
timing.start()
for i in xrange(10**6) : i == inst
timing.finish()
print timing.milli()
test(State)
test(StateFoo)
test(StateNew)
test(StateGT)
test(StateGTLT)
for which ouput is :
<class '__main__.State'>
589
<class '__main__.StateFoo'>
596
<class '__main__.StateNew'>
615
<class '__main__.StateGT'>
815
<class '__main__.StateGTLT'>
836
Can't say more about what in the internals of python produce this non
negligeable overhead, but looking at the source code of builtin comparison
(for new style classes as it seems we have not this overhead with old style
classes) should be the fist step...
--
_____________
Maric Michaud
_____________
Aristote - www.aristote.info
3 place des tapis
69004 Lyon
Tel: +33 426 880 097
--
http://mail.python.org/mailman/listinfo/python-list
