On Oct 23, 9:30 am, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Tue, 23 Oct 2007 15:34:19 -0000, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > [snip] > > >Calling time.time() is relatively inexpensive in comparison to pure > >Python function calls, but indeed, it could be a bottleneck. > > Did you benchmark this on some system? > > There isn't really any "pure Python function calls" that can replace > time.time() in a sensible way, so I made up one that does some random > things (including calling another Python function) and compared it to > time.time: > > [EMAIL PROTECTED]:~$ python -m timeit -s ' > def g(): > return 1. + 2 + 3 * 4 - 5 / 6 + 7 ** 8 > def f(): > return g() > ' 'f()' > 1000000 loops, best of 3: 1.39 usec per loop > [EMAIL PROTECTED]:~$ python -m timeit -s 'from time import time as f' 'f()' > 100000 loops, best of 3: 4.68 usec per loop > [EMAIL PROTECTED]:~$ > > Not really useful in any real-world sense, but I still wouldn't > characterize time.time as "relatively inexpensive." > > Of course, for any real-world work, one would want to profile the > application to determine if removing calls to time.time() could > make a worthwhile difference.
The particular function call he was talking about was the .readable() or .writable() in an asyncore.dispatcher subclass. Now, the trick with any nontrivial asyncore.dispatcher subclass is that you don't want to signal a socket as writable if you don't have any outgoing buffer. Similarly, I have seen subclasses that follows a state machine very strictly (no pipelining, you must finish sending before you can receive, etc.). In that sense, typically, both the .readable() and .writable() methods will reference an attribute or two of the instance. After running some tests, I notice that it seems like a not insignificant platform difference. Because on my platform (Windows and Python 2.3)... >>> setup = '''def g(): return 1. + 2 + 3 * 4 - 5 / 6 + 7 ** 8''' >>> timeit.Timer('g()', setup).repeat() [2.0143674536171798, 1.9778226522165654, 1.9959138650798764] >>> setup = ''' ... class foo(object): ... __slots__ = 'a', 'b' ... def __init__(self): ... self.a = 1 ... self.b = 2 ... def foo(self): ... return self.a and self.b ... ... inst = foo() ... ''' >>> timeit.Timer('inst.foo()', setup).repeat() [1.4185994550779242, 1.4186812879064519, 1.4478852871044694] >>> timeit.Timer('f()', 'f = lambda:None').repeat() [0.58938552412047329, 0.58762154196472238, 0.58324245809257036] >>> timeit.Timer('f()', 'from time import time as f').repeat() [0.68104482574668168, 0.64085672667252425, 0.6558844364245715] So to answer your question, even though I hadn't bothered to test it, my beliefs regarding time.time() being fast in relation to the particular operation he was expecting to perform, at least according to my own experience on the platform I use the most (Windows and Python 2.3) was relatively accurate, though indeed it is slower (but not much in comparison to what those calls would typically do). Then again, in the subclasses of asyncore that I write, I don't bother calling .readable() or .writable() at all, each socket adds and removes itself from a pair of readable and writable dictionaries automatically, thus removing perhaps hundreds of function calls for every loop of asyncore.poll . What these experiments also tell me is that fetching the time on linux is slow. But really, since I already wrote code that handles *all* of the timeout handling with a *single* time.time() call, and that also generally minimizes all explicit function calls, I'm not sure that your testing examples were ultimately germane to the conversation (how would one handle timeouts in asyncore). Or maybe it's just late and I've had a long day :/ . In any case, I'm glad that I was able to help Giampaolo. - Josiah -- http://mail.python.org/mailman/listinfo/python-list