D-BUS required changes in KDE 4

Olaf Jan Schmidt ojschmidt at kde.org
Thu Sep 14 12:13:34 BST 2006

[ 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 

> >* 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 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/

More information about the kde-core-devel mailing list