[ Thiago Macieira ]
> That test is laughable. Don't take it seriously any more than you take
> seriously any kiddie's benchmarking. It does some very weird testing and
> comes up with pretty inconsequential conclusions. String comparisons?!
> Please...

I mention it because it keeps being referred to in the FSG Accessibility 
workgroup as an obstacle for moving AT-SPI to D-Bus. Most FSGA members accept 
the test results as valid. The background is that IBM already started moving 
AT-SPI to D-Bus in the past and stopped it because they found their code to 
be slower than the existing CORBA/GNOME implementation (but they did not 
release their own performance tests AFAIK).

I tried to add an explanation why the test are useless to the wiki page 
http://www.freestandards.org/en/AT-SPI_on_D-Bus

> >* The main reason described in the analysis is the lack of caching for
> > DCOP and D-Bus. Would it be possible to add it?
>
> Caching of what?

Quote from the PDF file: 'From the above we can conclude that 
“dcopClient()->call” is the bottleneck. Delving into this a little it
seems that each time this function is called, the service target function is 
“looked up” i.e. there is no caching of function id's/references.'
And for D-Bus: 'Again, as is the case with DCOP here is a function lookup with 
no caching for subsequent calls.'

> >* Is D-Bus using sockets for local communication to improve the speed,
> > such as ORBit2 does? If not, would it make sense to change that?
>
> Yes, it's using sockets. What else would it be using?

tcp. What is used for remote communication?

> Now, libdbus-1 can use some optimisation in the marshalling code. My own
> tests indicate it can be slow. But compared to the two task-switches
> necessary to actually relay data to a remote process, that's negligible.

Optimisation is important for assistive technologies. Whenever a screen reader 
queries the user interface a web browser, a huge amount of calls for deeply 
nested user widgets are made. If this causes too much latency, then the 
system appears unreactive to blind users.

Olaf 

-- 
Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards 
accessibility networker, Protestant theology student and webmaster of 
http://accessibility.kde.org/ and http://www.amen-online.de/