D-BUS required changes in KDE 4

[johnflux at gmail.com]

Thiago,
  What would be the harm in optimising this case?  Even if you doubt
its use, but there's no disadvantage, why not optimise it anyway to
keep everyone happy?

  If you don't want to spend the time on it, would you reject a patch
from someone else?

John

On 14/09/06, Thiago Macieira <thiago at kde.org> wrote:
> 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
>
>