> Just a final note.. a single no-fds call to select with a 0 timeout seems to > take > around 280ns on my Core 2. Presumably the better interfaces (e.g. epoll, but
Are you sure there is actually a context switch happening with this syscall using no FDs and timeout 0? 280ns means your machine can do 3.5 millions selects() per second. Mmh. I have a hard time believing this would sustain with timeout>0 and/or FDs - anywhere near that magnitude. http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html > not poll) will also take around the same time. > > It's really hard to write even a single Python function that gets anywhere > below > 1usec CPU time, and given how function-heavy Twisted is, I'd be surprised PyPy: import timeit import time def f1(): pass def f2(x = 3): return x*x def f3(): return map(lambda x: x^2, range(10)) for f in [f1, f2, f3]: for i in range(5): print f, timeit.timeit(f, number = 1000000) time.sleep(2) oberstet@vbox-ubuntu1310:~/scm/scratchbox/python/twisted/timers$ ~/pypy-2.3-linux64/bin/pypy test2.py <function f1 at 0x00007f219ff0bd30> 0.00407981872559 <function f1 at 0x00007f219ff0bd30> 0.00138401985168 <function f1 at 0x00007f219ff0bd30> 0.00138092041016 <function f1 at 0x00007f219ff0bd30> 0.00148296356201 <function f1 at 0x00007f219ff0bd30> 0.00153708457947 <function f2 at 0x00007f219ff0bda8> 0.0269131660461 <function f2 at 0x00007f219ff0bda8> 0.0319480895996 <function f2 at 0x00007f219ff0bda8> 0.0243380069733 <function f2 at 0x00007f219ff0bda8> 0.0251939296722 <function f2 at 0x00007f219ff0bda8> 0.025454044342 <function f3 at 0x00007f219ff0be20> 0.474506855011 <function f3 at 0x00007f219ff0be20> 0.452003002167 <function f3 at 0x00007f219ff0be20> 0.446584939957 <function f3 at 0x00007f219ff0be20> 0.441245079041 <function f3 at 0x00007f219ff0be20> 0.467758893967 This is in a VM on low-end gear. My notebook actually. With trivial functions like above, PyPy might even optimize away funs altogether and inline those. Not sure though. > considerations like this factored usefully into a design at all :) > > Adjusting timer coalescing to extreme settings might even worsen your app's > performance, since it'll cause interpreter time and syscalls to all be > compressed around the slack intervals, leaving the CPU idle more often, rather > than running evenly spaced over time. This might produce less desirable app > behavior overall (e.g. it has knock-on effects for network interface queues, > bursts of disk IO/SQL queries, network switch buffer overruns, or whatever > else). I can see those points. Will keep in mind and measure. However, I am running a multi-process server, so as long as those processes tick slightly pitched w.r.t. each other, and there are more processes than cores, I guess I can saturate the CPUs. And then this is a network server, so there will be FD activity (lots of). It's just that I want to limit the impacts of having massive amounts of timers associated with network connections (ping/pong to detect lost TCP). In any case: thanks a lot for all your hints! /Tobias > > > David > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
