DBus and epoll

[Havoc Pennington]

Hi,

On Mon, Oct 25, 2010 at 8:46 AM,  <anttu.t.koski at nokia.com> wrote:
> Well, not really. I just checked my traces and they show that generally dbus-daemon seems to spend most of its time in _dbus_poll() and the time increases with the number of file descriptors.

You'd expect it to spend most time in poll, right? Unless there is
continuously incoming data, you'd want most time to be spent waiting
for more data. The alternative is to be "getting behind" on processing
the data because it takes too long to process.

The question is how much time is spent on "poll overhead" (dealing
with the list of fd structs), which is sort of harder to profile.

Anyway I think a nice change would be to make dbus-daemon use an
internal copy of libev, which is a super fast mainloop library that's
just one file, which we could paste in. (libev doesn't even work right
with a "system copy", the API depends on #defining things that affect
the ABI, so it's designed to only be used as an internal copy.)
See http://software.schmorp.de/pkg/libev.html
I've used this before and it works well, is fast, and doesn't add a
dependency. node.js uses it for example. Would add support for epoll
and also kqueue and whatever.

Havoc