Re: SoC idea: desktop file cache

[Juan Pablo <juanpablougarte gmail com>]

El 25/03/2011, a las 12:17, Colin Walters <walters verbum org> escribió:

> On Fri, Mar 25, 2011 at 11:12 AM, Johannes Schmid <jhs jsschmid de> wrote:
>> Hi!
>> 
>> After reading Alan's and David's comment it occurs to me that it could
>> be way simpler to have a dbus-service handling the desktop files and
>> anybody wanting to access the desktop files in a fast way can use that
>> service (through a library wrapper).

I agree with Johannes

> I don't think that would make things faster; in fact it'd be more
> likely to make them slower.  DBus is just not designed for bulk data
> transfer.  Think about it - the bus daemon sits in the middle, copying
> strings around etc., have to be read in and out...

I do not think memcpy would be the bottle neck in this case.
Granted having this dbus service would use more ram, but I do not think that is a issue not even in embedded systems (last one I work with had 1gb)

It might be a little bit slower the first time depending when you launch the service.

But If you make sure the service is up with all the entries in memory before the first app request then things will be faster.

Now if we want to speed up reading all these small files. I would suggest creating a zipped tarball containing all the desktop entries.
Not only we get some speedup from the fact we had less data to read but also because there is a good chance most of the file blocks will be contiguous.
Which could be part of the standard so every time someone adds an entry is responsible for updating it or it could be updated by the dbus daemon itself.

For the later I would use the md5 of all the file names + modification time as the tarball name.

In any case I volunteer to implement such thing.

Cheers

Juan Pablo


> One thing that we should probably promote more about GNOME 3 is how
> far we are long in kicking GConf out, which had this
> single-threaded-centralized-daemon model.  When I was doing some
> profiling a while back, I was surprised by the extent to which gconfd
> acted as a serialization point for the entire desktop, especially if
> you didn't use PRELOAD_RECURSIVE for reading keys.
> dconf is just way better.
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list