Re: [g-a-devel] AT-SPI caching and D-Bus usage

[Jason White <jason jasonjgw net>]

Mike Gorse <mgorse alum wpi edu> wrote:
> AT-SPI was originally designed around CORBA, specifically ORBit. Its
> use led to a large amount of inter-process communication. Method
> calls in ORBit were fairly quick, so this was not a huge problem,
> although that isn't to say that there were never performance issues.
> However, ORBit was deprecated for GNOME 3, and Codethink undertook
> an investigation of the feasibility of porting AT-SPi to D-Bus. Note
> that the D-Bus libraries were not really designed to be used in
> cases where a large amount of synchronous method calls are needed.
> Nevertheless, Codethink undertook an investigation of the
> feasibility of porting AT-SPI to D-Bus. Their main conclusions were
> that, although D-Bus method calls are slower than the equivalent
> CORBA calls, a lot of AT-SPI traffic generated by Orca comes from a
> handful of method calls--calls to fetch an object's name, parent,
> children, or state set, for instance. If these data could be cached,
> then a significant amount of traffic would become unnecessary.

How will this performance analysis change when/if DBus is implemented in the
Linux kernel?

The module for doing so already exists; it is currently under development by
experienced kernel authors, with the intent to merge it into the mainline.
Apparently, it's much faster than the current implementation.