dbus profiling
by havoc
I did some dbus
optimization a while back, but it got lost when we rewrote all the
marshaling code to support fully recursive types. Unfortunately, the
code now has a distributed bloat
problem where the performance issue comes from too many “layers” – to
speed this up I think we need someone to come in with an ugly stick
and do more hard-coding and special-casing and general
de-genericization/de-abstraction.
Usually this kind of speed-over-sanity is one big Bad Idea in desktop
programming (though the kernel and libc are full of it) but maybe dbus
is an exception if we want it to stack up well vs. other
binary-protocol IPC systems. Then again, if we look at the desktop as
a whole dbus is unlikely to be a bottleneck so “who cares” could be
the right answer. We just have to ignore whining from anyone running
dbus vs. other-IPC-thingy benchmarks.
On the plus side, the dbus TODO for 1.0 is
looking awfully short.
(This post was originally found at http://log.ometer.com/2005-07.html#29)