From kde-core-devel Thu Sep 14 20:17:31 2006 From: Thiago Macieira Date: Thu, 14 Sep 2006 20:17:31 +0000 To: kde-core-devel Subject: Re: D-BUS required changes in KDE 4 Message-Id: <200609142217.31908.thiago () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=115826510127957 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1633125.5utcltuLcI" --nextPart1633125.5utcltuLcI Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 optimised as existing solutions -- yet. And, yes, it's slower than DCOP because it's correcting a few shortcomings= =20 we had in DCOP. This is to ensure maximum interoperability. That's the=20 price we pay for progress. For anyone that disagrees, I suggest you erase=20 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 >=E2=80=9CdcopClient()->call=E2=80=9D is the bottleneck. Delving into this = a little it >seems that each time this function is called, the service target > function is =E2=80=9Clooked up=E2=80=9D i.e. there is no caching of funct= ion > 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=20 even a dichotomic. It's a simple string search. If that ever shows up as a bottleneck in *real world* situations, it'll be= =20 fixed. Of course it's going to show up in a test-case whose only job is=20 to place thousands of calls: something HAS to show up, since that's all=20 it does. And as I said before, the task switching associated with the=20 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=20 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=20 optimise blindly. =2D-=20 =C2=A0 Thiago Macieira =C2=A0- =C2=A0thiago (AT) macieira.info - thiago (AT= ) kde.org =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint: =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4 5358 --nextPart1633125.5utcltuLcI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFCbjbM/XwBW70U1gRAmD3AKCaO0ci2rwaJmJwWmifpesGuUYvhgCdGr0Q B5vF/bzGaEaebGrYtH/gYLw= =rvll -----END PGP SIGNATURE----- --nextPart1633125.5utcltuLcI--