Excess disk (dconf) writes

Probably a granite problem, I am not even sure it is fixable. (I was
against the Granite.Settings class, using GSettings directly avoid this
kind of problems and we don't need an abstraction layer like that.)

Le vendredi 30 mars 2012 à 11:03 +0000, Sergey "Shnatsel" Davidoff a
écrit :
> Public bug reported:
>
> Slingshot writes the following dconf keys:
>
> /desktop/pantheon/slingshot/open-on-mouse
> /desktop/pantheon/slingshot/show-category-filter
> /desktop/pantheon/slingshot/icon-size
> /desktop/pantheon/slingshot/rows
> /desktop/pantheon/slingshot/columns
>
> every time I open or close it. This creates disk activity which we could easily avoid.
> Keep in mind dconf is read-optimized, it doesn't do equally well on writes (a read requires 1 system call while a write requires 4).
>
> ** Affects: slingshot
> Importance: Undecided
> Status: New
>

And I think that there is this problem with all elementary applications now you say it.

+1 to the report and the comments. Binding settings to properties is definitely not a good practice. At least not for properties that change their values in memory during startup, etc.

Lucas, I second you on not using the settings abstraction layer. If you have the time to do the change, it would be awesome if you modified slingshot to manage its settings by itself and fix this bug by the way.

Maybe you could leave the settings class as it is, but on every potential write read the value and if it's the same, don't write it... dconf assumes there are much more config reads than writes in your daily life, so this should be cheap.

Hmmm, the problem is that. Some properties change lots of times in small intervals of time. For example, UI properties, etc. Maybe we should add an option to "mute" writing to settings temporarily.

This defeats the point of having Granite.Settings at all IMHO

I believe agent00tai was hacking this

I think that my branch will correct it...