Request for the 1.0 release

[Havoc Pennington]

Hi,

A couple more performance notes I thought of that might be interesting
in case we have a list lurker who dives in:

1) If you are willing to always do blocking writes (or know you will be
blocking in a particular case), we don't need in theory need to allocate
and copy into a DBusMessage; we could just marshal data into the socket
directly.

A problem, though, is that right now the protocol has lengths right at
the start of the message (itself an optimization in some other
situations). 

This makes it harder since you have to walk over the args and compute
what the length of the message will be, then go back and write out the
args.

But still, when sending a big byte array or something this could be
noticeably faster than first copying into a message and then writing the
message.

On the other hand, DBusMessage has the effect of putting the whole
message body in one big buffer and thus we only call write() once to
write the body out - if we didn't copy into a single buffer, we'd have
to call write() once per method argument. Which could well be slower
than creating the DBusMessage, depending.

In the bus daemon, the same DBusMessage that was read in can be written
out again, which is a nice optimization we already have.

Still, if I wanted a really, really fast libdbus implementation I'd
probably make it "blocking only," which would make the whole lib a lot
smaller and simpler too. But people who wanted async would be forced to
use threads.

2) In Xlib apps, round trips and latency are often a bigger issue than
bandwidth or data volume. dbus is designed to let you avoid round trips,
e.g. push out lots of requests, then gather all the results at once; or
avoid blocking when a signal is emitted. It's probably useful to design
bindings and apps with this in mind as well. I think this is especially
of interest when an application starts up, if it needs to contact a
bunch of desktop services, the desktop framework libraries could fire
off async requests for those, then do other stuff, then harvest all the
results.

This approach is what makes Metacity the champion window manager in
window mapping throughput, because it can suck all the properties off a
window in a single round trip! OK, not one of the most important
accomplishments in my life ;-)

Havoc