Excess disk (dconf) writes

Bug #969077 reported by Sergey "Shnatsel" Davidoff on 2012-03-30
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Granite
Fix Released
Critical
Unassigned
Slingshot
Fix Released
Critical
Andrea Basso

Bug Description

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

Related branches

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
>

affects: slingshot → granite
xapantu (xapantu) wrote :

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

Victor Martinez (victored) wrote :

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

Victor Martinez (victored) wrote :

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.

Changed in granite:
importance: Undecided → High
status: New → Confirmed

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

Cody Garver (codygarver) on 2012-04-14
Changed in granite:
milestone: none → 0.1.1

I believe agent00tai was hacking this

Daniel Fore (danrabbit) on 2012-05-22
Changed in slingshot:
importance: Undecided → Critical
milestone: none → luna-beta1
status: New → Confirmed
Changed in granite:
importance: High → Critical
Changed in slingshot:
assignee: nobody → Andrea Basso (voluntatefaber)
Changed in slingshot:
status: Confirmed → Fix Committed
Corentin Noël (tintou) wrote :

I think that my branch will correct it...

xapantu (xapantu) on 2012-06-30
Changed in granite:
status: Confirmed → Fix Committed
Daniel Fore (danrabbit) on 2012-11-09
Changed in slingshot:
status: Fix Committed → Fix Released
Changed in granite:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers