"DBus Embedded" - a clean break
thiago at kde.org
Thu Jan 20 03:56:28 PST 2011
On Thursday, 20 de January de 2011 09:53:38 Ville M. Vainio wrote:
> Just some subversive thoughts (not a practical development project for now):
> - Dbus is very slow. It's okay on desktop, but on mobile platforms
> it's suboptimal
The above is true, we all agree. But we also have a population of 1 to
benchmark on mobile platforms: libdbus-1. We don't know for sure whether it's
the library that is slow or if the protocol cannot be made faster by anyone.
My guess, knowing the code, is that the library is slow. I know it does
verification and re-verification of messages. We all know that it has not been
optimised since the recursive message system was added to it for version 0.50,
back in 2005.
So D-Bus being slow is not a surprise, it's a realisation that no one has
invested proper time in optimising it.
> - It could be much (10x?) faster - switch to shared memory, posix
> message queues for data transmission (references to relevant shared
> memory blocks), do not do any verification
The "no verification" is for sure a way to improve performance. The others
above are unknowns, since there are no substantial studies.
> - Switch to peer-to-peer communication as soon as possible while doing
> the handshake through daemon (minimize context switches, transmission
Would buy you 4x at most, in the theoretical case.
> - It should be possible to make apps using libdbus to still work with
> this new structure, to retain application compatibility. Obviously
> wire protocol disappears completely.
> - Retain the current serialization functionality. However, provide a
> way to skip it (since people say it's one reason why dbus is slow) and
> transmit raw binary data very quickly.
What's wrong with the serialisation? And more importantly, how are you going
to lay data out on the wire ("wire" stands for any kind of inter-process
medium) so that two processes can read it?
The D-Bus serialisation protocol is actually very good for shared memory
access. It respects even alignments. DConf uses it for its on-disk memory-
> Implementing this might be easier than fixing dbus, and it could get
> rid of thread synchronization problems. It would definitely fix speed.
Yes, it might be easier than fixing libdbus. We have no clue if the D-Bus
protocol needs fixing. We also don't know for sure that it is easier.
I know the current implementation is slow. We all know this. What irritates me
is that people jump to conclusions that "since it's slow today, it's
fundamentally flawed, cannot be fixed, we should just write a new thing". There
is no proof in that statement above. We don't know for sure.
What irritates me is that no one has *tried* to optimise the library in the
past 6 years I've been involved with D-Bus!
So it's slow, sure, but because no one cares about making it faster.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the dbus