Adding idle timeout capabilities to asyncore

[Josiah Carlson]

On Oct 23, 9:30 am, Jean-Paul Calderone <exar... at divmod.com> wrote:
> On Tue, 23 Oct 2007 15:34:19 -0000, Josiah Carlson <josiah.carl... at gmail.com> 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:
>
>   exarkun at charm:~$ 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
>   exarkun at charm:~$ python -m timeit -s 'from time import time as f' 'f()'
>   100000 loops, best of 3: 4.68 usec per loop
>   exarkun at charm:~$
>
> 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