D-BUS required changes in KDE 4

Thiago Macieira thiago at kde.org
Thu Sep 14 21:17:31 BST 2006


Olaf Jan Schmidt wrote:
>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).

Ok, it's as good as vapourware then.

>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

Good point: D-Bus is a new thing. Of course it's not going to be as 
optimised as existing solutions -- yet.

And, yes, it's slower than DCOP because it's correcting a few shortcomings 
we had in DCOP. This is to ensure maximum interoperability. That's the 
price we pay for progress. For anyone that disagrees, I suggest you erase 
Linux and install DOS 1.0 on your computer.

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

True, there's a lookup that is made for each function call and that's not 
even a dichotomic. It's a simple string search.

If that ever shows up as a bottleneck in *real world* situations, it'll be 
fixed. Of course it's going to show up in a test-case whose only job is 
to place thousands of calls: something HAS to show up, since that's all 
it does. And as I said before, the task switching associated with the 
delivery of calls takes a lot longer too.

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

Unix sockets for the system and session bus and whatever you choose for 
your local P2P socket (Unix streaming or TCP).

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

Agreed. I'd like to see some tests in those *real world* cases. I can't 
optimise blindly.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060914/f24da658/attachment.sig>


More information about the kde-core-devel mailing list