Performance: (was Re: [Accessibility] Re: [Accessibility-atspi] D-Bus AT-SPI - The way forward)

[Rob Taylor]

Havoc Pennington wrote:
> Performance
> ===
> 
> D-Bus performance is already well-known and pretty well understood; I
> got the same results as the AtSpiDbusInvestigation page in 2004:
> http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html
> and updated information and suggestions related to this here:
> http://lists.freedesktop.org/archives/dbus/2007-October/008822.html
> 
> The basic fact is that for a round-trip blocking method call there is a
> constant-factor overhead of around 3x vs. raw sockets. (ORBit is not a
> lot slower than raw sockets, iirc.) If you use the bus daemon, this
> inherently doubles, since there are double the number of "hops." Looking
> at the causes of this overhead, it is difficult to change fundamentally;
> I'm sure with effort you could get it down to 2x, and perhaps a bit
> better by writing a libdbus replacement with less flexibility. But you
> won't get to 1x.

Ok,its worth taking a look at
http://live.gnome.org/GAP/AtSpiDbusInvestigation/IPCResults

3x on a direct connection is pretty much the worse case wrt ORBit.

> The constant factor falls out of a number of design decisions, some of
> them in the protocol, and others in libdbus. This was intentional. My
> opinion is that these decisions were largely correct, but opinions vary.
> (Some of the design decisions are easy to explore changing, such as
> whether to validate the data; see the archive links above.)

Yep, actually turning off validating the data had a suprisingly small
effect. I've pulled together some data (on my X40) for making simple
in:none, out:int calls on a direct connection, showing validated against
validation disabled and also using prebuilt DBusMessages (and
dbus_message_copy) versus actually marshalling the message. See the
attached gnumeric spreadsheet. The source for the tests can be found at
http://git.codethink.co.uk/?p=ipc-benchmarking (the atspi/role-client
tests).

The interesting thing here is even when doing no marshalling and with
validation disabled, its still at about 2x against ORBit. What other
design decisions do you think might be influencing this?

> Given that fact, I don't think there is much more to say. There is no
> way application design should vary based on whether 2x or 3x was
> measured. Unless you intend to hack on libdbus itself and want to drill
> down into hotspots to fix them, what you as an app developer should have
> in your mind is "there's a single-digit constant-factor overhead vs. raw
> sockets" and "avoid round trips!!!!"

Well, in terms of performance fixing, that's pretty much what I'd like
to do :)

> For AT-SPI I bet the bottom line is that you guys have got to reduce the
> amount of traffic and round trips, probably by changing or extending the
> API.

There's only so much that can be done here, as in there's a lot of
existing code out there already based on the current API. Some simple
things like enabling cachable properties could make a huge difference,
but even there there's a lot of assumptions in things like mozilla's ATK
usage that break when doing that.

Having said that, we do have the chance to rethink things here.

> If you need something raw-socket-like, then stick to CORBA, or use D-Bus
> for discovery only then set up a custom socket channel, or whatever.

There's certianly benefits to being able to use the same wire format
everywhere. Shall we see what we can do in terms of performance first
rather than designing a system on the assumption that performance with
D-Bus will always be bad?

> There is no reason to drop CORBA when it is suitable. The reason for
> dbus is that (in my opinion) CORBA was not suitable for many desktop
> use-cases. That does not mean CORBA is not suitable for AT-SPI.

The background to investigating moving AT-SPI over to D-Bus can be found
at http://live.gnome.org/GAP/AtSpiDbusInvestigation/Background

Personally, I see this as a good chance to make good on a lot of those
plans we've had floating round for a while and generally improve D-Bus.

Thanks,
Rob
-- 
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-results.gnumeric
Type: application/x-gnumeric
Size: 2833 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20071213/278b603f/attachment.gnumeric