--nextPart2574946.t0u21ZQRcJ
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 07 December 2004 19:33, Maksim Orlovich wrote:
> > I guess it depends on your scheduler and on the amount of parsing /
> > context switch. How many config keys do you want to transfer / call?
>
> Well, the original message seems to suggest "individual keys", which IMHO
> is quite risky.

I agree.

> The (IIRC) GConf approach of pushing an entire hierarchy=20
> specific to the app + the globals seems reasonable.

Yes, I believe they discovered that individual keys was not good for=20
performance.

> A very rough indicator for this sort of thing is likely the latency of the
> konqueror-* calls that are mased by the HistoryManager --- a bit back I've
> seen that they come up as ~20ms or so per process, which is quite a lot.
> (actually, I should probably profile that again now that I understand DCOP
> better)

Would be nice to have some data indeed. Maybe we can add some test-scripts =
to=20
the dcop dir, and measure various call patterns. Would be useful later on f=
or=20
comparing performance with DBUS.

> The big difficulty with a daemon-like approach, though, is deciding what
> sort of consistency guarantees it provides. If one permits the sort of
> mild races that are possible w/the current setup, it's probably not too
> hard to make it efficient. Making sure everything is in top shape, though,
> can get quite messy and expensive....

We currently provide soft guarantees by default and since KDE 3.3 we can=20
provide hard guarantees if the application cares enough. I think that can b=
e=20
mapped relatively straight foward to a daemon approach.

Cheers,
Waldo
=2D-=20
bastian@kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian@suse.com  |   http://www.novell.com/products/desktop/eval.html

--nextPart2574946.t0u21ZQRcJ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQBBth+EN4pvrENfboIRAoTkAKCovv5uWcx5J7gngYCvSk0K/ih74gCffvIj
dRGy1JtGmGp7Ba49RK+qz4E=
=3Y1g
-----END PGP SIGNATURE-----

--nextPart2574946.t0u21ZQRcJ--