[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: XML/XSD based configuration files.
From:       "Maksim Orlovich" <mo85 () cornell ! edu>
Date:       2004-12-07 18:33:28
Message-ID: 33144.128.84.98.4.1102444408.squirrel () 128 ! 84 ! 98 ! 4
[Download RAW message or body]

> On Tuesday 07 December 2004 19:09, Maksim Orlovich wrote:
>> > The problem is transfering the data from one process to the other.
>> That
>> > will
>> > most likely involve some sort of marshalling and the time you need for
>> > that
>> > is in the same order as reading the file from disk. (Only the first
>> time
>> > you
>>
>> Huh? Since when is marshalling more expensive than scheduling latencies?
>
> 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. The (IIRC) GConf approach of pushing an entire hierarchy
specific to the app + the globals seems reasonable.

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)

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

On a side note there may actually be a memory-savings merit to mmap'ing
stuff from a daemon, too, though probably not that much


[prev in list] [next in list] [prev in thread] [next in thread]