On 11/4/12 8:11 AM, Ben Darnell wrote:
The extra system calls add up. The interface of Tornado's IOLoop was based on epoll (where the internal state is roughly a mapping {fd: event_set}), so it requires more register/unregister operations when running on kqueue (where the internal state is roughly a set of (fd, event) pairs). This shows up in benchmarks of the HTTPServer; it's faster on platforms with epoll than platforms with kqueue. In low-concurrency scenarios it's actually faster to use select() even when kqueue is available (or maybe that's a mac-specific quirk).
Just so I have this right, you're saying that HTTPServer is slower on kqueue because of the IOLoop design, yes? I've just looked over the epoll interface and I see at least one huge difference compared to kqueue: it requires a system call for each fd registration event. With kevent() you can accumulate thousands of registrations, shove them into a single kevent() call and get thousands of events out. It's a little all-singing-all-dancing, but it's hard to imagine a way to do it using fewer system calls. 8^) -Sam