Re: AT-SPI caching and D-Bus usage

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