"DBus Embedded" - a clean break

[Thiago Macieira]

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

Hi Ville

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
> counts).

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.

Agreed.

> - 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-
mappable files.

> Implementing this might be easier than fixing dbus, and it could get
> rid of thread synchronization problems. It would definitely fix speed.
> Thoughts?

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
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20110120/f0684e81/attachment.pgp>