On Wed, 2004-09-29 at 19:32 +0200, Waldo Bastian wrote:
> It would be nice to have some comparison data on performance indeed. I don't 
> see any particular reason why DBUS would need to be any slower than DCOP, the 
> main task of both is to move data into and out of a pipe. The connection part 
> may show significant differences wrt performance though, depending on the 
> kind of authentication/authorisation that is performed. We definitly need to 
> gather data on that.

To be honest I would expect that if you profile dbus today it's a fair
bit slower, just because I haven't profiled it in a while. Last time I
profiled it the top time usage was UTF-8 validation for strings...
something we could turn off for the per-session bus probably.

Anyhow, any not-recently-optimized codebase will have a couple of "doh!"
in there. But I don't know of reasons dbus is *inherently* slow,
especially the protocol. My implementation has some paranoia-first-
speed-second leanings, such as the UTF-8 validation, but we could tune
that tradeoff as desired.

One thing I've been striving for is to avoid copies of large blocks of
data, so it comes off the wire in aligned binary format and can be used
in-place. Right now the public accessor functions to some of the data
types will make a copy; a nice easy optimization would be accessors that
get the raw/const data so there's no pointless copy when you expect to
copy into a Qt type anyhow. 

Another thing I've been striving for is to be able to do everything
async and without round trips. This may cause slight slowdowns in the
"echo client/echo server" kind of profile, but speed up other cases such
as application startup time.

Anyhow, it's all pretty tunable/fixable as required.

Havoc