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

[Mike Gorse <mgorse alum wpi edu>]

On Sat, 12 Oct 2013, Jason White 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?

I have no idea, actually.

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

That's good to know; it sounds worth looking into.

Thanks,
-Mike