gsettings is fast

sometimes people will come up to me at a conference and one way or another mention that they are avoiding using gsettings because they need their app to start “really fast”. at uds for example, someone asked me “i should be using a keyfile for this, right?”.

gsettings has dconf as its backend. there are a couple of things that i assumed were common knowledge about dconf that surprised people when i told them. the main two things to note are that the on-disk dconf database is a hashtable that gets mmaped into your process and that reads (after the first read) typically involve zero system calls — just direct access to the hash table.

i still decided that it would be helpful to get a hold on some actual numbers here, though. i did some testing (nothing serious — but it gives a good idea of the ballpark figures involved here).

my methodology for measuring how long it takes to do something is this:

time (for i in `seq `1000` do; ./something; done > /dev/null) and dividing the ‘real’ time by 1000

running ‘/bin/true’ takes about 1.1ms
running a do-nothing program linked against libgio and calling g_type_init(): 2.2ms

when i went to benchmark gsettings i noticed that it was a bit slower than i thought. about 9ms to run the gsettings command line tool to “get” a setting. (for comparison, initialising gtk is 30ms and qt 350ms). still, i was wondering why it was so slow. it turns out that the largest part of that was that i was blocking on gdbus initialisation which (due to the chatty nature of the dbus protocol initialisation and the fact that dbus-daemon is a slow talker) takes quite a long time. gdbus needs to be initialised along with gsettings in order to add match rules for change notification.

i’ve fixed the backend so that we don’t block on gdbus initialisation anymore — it happens asynchronously and in another thread. those changes will land on master today. after the changes, running the gsettings commandline tool in ‘get’ mode takes about 4.2ms.

so for the record: the cost of initialising gsettings and reading a value out of dconf adds about 2ms to your program startup — less than 1/10th of the time it takes to initialise gtk and on the same order as the length of time it takes to spawn the process, load the shared libraries and call g_type_init().

gtk hackfest summary

the gtk hackfest came to a conclusion a bit over a week ago. since then we’ve had a gtk team irc meeting with the release team present to discuss the results.

first, i’d like to thank everyone who came to the hackfest for the awesome work done. also, thanks to the gnome foundation for paying for the hotel and to the companies involved for sending their people (thanks to codethink in my case). thanks also to codethink for sponsoring the catering and lunches and lanedo for the “official dinner” of the hackfest. a very big thanks goes to igalia for the hosting and particularly to alberto garcia for being a completely awesome host — seriously, you rock.

the biggest news out of the hackfest is that we have a very solid roadmap for the future of glib in gtk in two ways. first, the path to gtk3 is very clear at this point. we have an ambitious but realistic feature list for what we want to see added in the next two months and each feature on that list has a name assigned to it. it’s a heck of a lot of work, but the release is currently on schedule and things are proceeding quite smoothly.

second, we have a list of things that we want to take care of for a future glib4/gtk4 release.

both of those lists are in a rough form here:

the roadmap is going to be polished and put into a more user-centric form at the upcoming boston summit (this weekend).

perhaps the most surprising takeaway from the hackfest is that gtk4 is coming quite soon. we plan to do the bulk of the work required to get it out the door in 2011. we were originally saying that we’ll target the gtk 4.0 release for “december 2011” but we’ve decided that it’s probably a little bit too much to say that and rather we will say that we want a feature-complete beta release by that time. of course, deadlines being as they are, who knows what will happen….

we plan to open up a gtk4 branch as soon as gtk 3.0 is out the door. we also plan to have another gtk hackfest in the spring of 2011, and we may find ourselves wanting one again in the fall.

having two major releases with so little time between might seem very weird. we tried for quite some time to consider reasonable alternatives (which is part of why this blog post is so far delayed). the decision here comes down to two simple facts. first, gtk 3.0 is required for gnome 3.0 and was promised for christmas. second is that we have an awful lot of well-directed momentum at the moment and we have a lot of really large changes that we want to make that won’t fit into a 2 month window.

something also worth mentioning, for those who didn’t know, is that samsung sent 3 engineers to the hackfest. for some time now, they’ve had a team of hackers (somewhere in the area of 20-30 strong) working on a phone based on gtk, to be released soon. they had a pretty slick prototype present and brought some interesting viewpoints to the discussion. boram park (one of the samsung engineers) also contributed samsung’s first “direct” upstream patch to gtk during the hackfest.

as for myself, my personal focus on gtk3 and glib 2.28 for the next two months falls into two large tasks. one: fix time in glib and get GPeriodic spiffed up and make sure that it’s properly wired up as a paint clock for gtk. two: get GtkApplication rocking with some nice features like full shell integration, automatic session management and the like. i’m particularly interested in feedback from early adopters about ways in which i could make your life easier.

i’m going to be at the boston summit again this year, and there will surely be a lot of discussion there on getting the gtk3 story closed.


this week i’m at uds with vuntz and andreas.

there was obviously a big announcement yesterday. enough people are commenting on that already, and i don’t have anything that i really want to add to that conversation.

on a more positive note, i want to mention something that was agreed during one of the desktop sessions yesterday morning.

based on a promise made by jono bacon that gnome-shell would be an absolutely first class citizen in ubuntu (just not included on the CD) and in response to the lessons learnt from the failure of “stracciatella gnome”, we proposed the creation of an environment variable. if set, it disables the effects of any ubuntu vendor patch to upstream components when those effects are related to gnome-shell vs. unity integration.

what this means is that you will be able to login to a gnome-shell ubuntu experience that works properly, without all of the applications assuming that they are trying to interact with unity.

i like the name GNOME_ME_HARDER, but i guess they’ll probably want to do something a little more boring.

the specific parameters of the promise that was made are as follows:

1. for new vendor patches, this “works with shell” functionality will be required in order for the patch to be considered functionally complete for inclusion.

2. for existing vendor patches, missing GNOME_ME_HARDER functionality will be considered as a bug. this means that issue will receive the same treatment as other bugs — it will be fixed if there is time, patches welcome, etc.

gtk hackfest, day 2

codethink sent me to the gtk+ hackfest this week, hosted in the igalia offices. some really nice things are happening there so far.

first of all, i landed GApplication on glib master (and in gtk too). sorry for any breakage that may have caused. actions support should be coming soon…

second, after some discussion with emmanuele, i sent out to write a paint clock that could be shared by both gtk and clutter. i stayed up until 4am last night dumping my brain into vim and the result of that work is in glib (gio) in the form of GPeriodic. there is also a branch in gtk (wip/paint-clock) that uses GPeriodic to schedule repainting of windows and (for example and proof of concept) to animate GtkSpinner. presently cody is working on a somewhat less-trivial case: making GtkExpander animate smoothly. emmanuele is currently attempting to rebase clutter’s master clock on top of it, so the end result is that clutter and gtk should be on the same clock by the end of the week.

there is not currently any support for merging of input events. that’s mostly due to the fact that it’s a really hard problem and we probably won’t get a chance to deal with it at all before 3.0.

the other thing that we’re working on this week is reducing the GdkWindow abuse that occurs in gtk. samsung sent a few hackers to the hackfest, and one of them (boram) is trying to replace the 2+n input/output GdkWindows in GtkEntry with input-only windows. we believe that this is a reasonable intermediate step to improve use of the new gtk_widget_draw() api without having to think about the input issues (again, because they are quite hard).

i’m personally about to set out on a GtkViewport reimplementation that, first, behaves very naively by always redrawing everything and later caches the content of the scrolled area in an offscreen window (including some of the non-visible areas as a sort of pre-fetching).

there is some talk that gtk4 may be coming in the nearer future than any of us anticipated……

GSettings update

after quite some time, the GVariant, GSettings, dconf saga is coming to an end. for quite some time Codethink has been sponsoring me to spend a fair bit of time on this stuff and i’m happy to say that it’s reaching the point of usability.

first of all: all existing code is now merged to its final destination. no weird branches or anything are required to use the latest stuff. in fact, i made a pair of tarball releases yesterday: one for glib and one for dconf. those are all you need.

install instructions are something like this:

1) install glib
2) install dconf
3) profit!!

i hacked together a quick example of what #3 might look like. check it out on (not in gnome git due to the fact that it will probably bit-rot soon).

a few notes with respect to the recent releases:

1) the m4 macro for GSettings has changed. if you’re an early adopter this will burn you and i am sorry. the new macro is much nicer, though. it’s less typing for you and it fixes a few problems with the old macro.

to use it, you just need to have two lines in your

gsettings_SCHEMAS = one.gschema.xml two.gscema.xml ...

make sure your ACLOCAL_FLAGS is setup properly if you’re using glib installed in a strange prefix because otherwise aclocal won’t find gsettings.m4.

2) the dconf release as of yesterday has a small bug with an extremely large impact: the gio-querymodule support is broken which causes the dconf GSettings backend not to be seen if you run the gio-querymodule tool. this has been fixed in git and will be in the next release (which should be along in a few days) and it only affects you if you run the tool. my understanding is that vendor packages are working around the issue already.

vendor packages are coming for fedora (rawhide) and ubuntu (maverick, plus backported to lucid in an official ppa). your least-pain option is probably to wait for these.

the next release of dconf will be focused on using it outside of GSettings; a standalone client-side library, and a commandline tool. Robert Ancell has also signed on to do some work on a graphical editor.

one last note: dconf is currently extremely slow. “hilariously slow” might be the appropriate thing to say. don’t worry — it’s just a small fix to make that better. for now i’m more interested in features work, though.

one more last note: the dconf file format might change. just so you know. :)

two notes on gsettings

1: the gsettings hackfest is on. april 12 – 17 in cambridge mass. see for more information. the goal is to get gsettings stable and merged into glib and to port some of the big desktop applications to it (panel, nautilus, evolution, etc). walking away from this hackfest we should be in a spot where it is reasonable for other applications to port themselves.

2: gvariant (the type system on which dconf, gsettings, gdbus and other things are based) is almost entirely merged into glib. only one small part (parsing of text values) is outstanding. all other functionality is there as it will be in the next glib stable release. if you’re a present user of gvariant from the branch then please take a look at the master branch and make sure everything is as you expected — if you don’t say anything then this is what will become the official API.

i also did my first release of glib today (including the latest gvariant goodness). i think that was a good thing, although now i’m starting to have second thoughts…

12:24 <bratsche> desrt: Are you maintaining glib now or something?
12:25 <desrt> bratsche: no.  just helping a little.
12:25 <mclasen> bratsche: psst, he doesn't know yet

i just returned from boston summit. boston summit is always scheduled on canadian thanksgiving which usually means that i can’t attend, but this year i bit the bullet.

i’m glad i did.

the three days of the conference were perhaps the three most productive days i have spent at any event. the entire attendence was on the order of about 30-40 people. this allowed the format to be very informal, and the level of focus allowed by that was fantastic.

for me, one of the happiest things to report is that i had a “hallway track” talk with davidz, mclasen and wjt. a very nice conclusion came from this talk. the upshot of that conversion is that the following items are all likely to occur:

  • GVariant will be included in the next stable release of glib
  • GDBus will be included in the next stable release of glib
  • GDBus will be modified to be based on GVariant

already, davidz has ported GDBus to GVariant and he reports that it’s working very nicely. you can see that work in the gdbus-standalone git repository.

while in boston, i proposed dconf as a new module for GNOME 2.30. reception on d-d-l has been very positive. this means that the following two points are also likely:

  • GSettings will be included in the next stable release of glib
  • dconf will ship with GNOME 3.0

a couple of other things that really stuck out for me from the summit:

gnome-shell: it seemed to me that the number of people using gnome-shell on their laptops increased substantially over the course of the summit. i’ve personally switched over to using it full-time. it’s weird and a little bit strange, but there are some things about it that i really like. i’ve also been showing it to some “normal humans” since coming back and they think that it’s pretty cool too.

splinter: in case you haven’t heard, we now have patch review integrated into GNOME bugzilla. click the “review” button beside the patch. kudos to owen for this.

that’s all for this post. i have a couple of new projects that i’m working on as a result of the summit that i will talk about soon.

“be excellent to each other”

it’s perhaps a bug in the ubuntu code of conduct that it does not include something that we can find elsewhere — in the KDE code of conduct.

i believe that “be excellent to each other” very much includes “assume that people mean well”.

i’m personally a bit tired of seeing people repeatedly publicly flogged for an innocent action (where i define innocent as “very obviously without malice”).

ps: can we please get back to work? boston summit just ended today and i can tell you that there is certainly no lack of actual interesting things to be spending time on.

edit: thanks to murray for pointing out that the “assume people mean well” language appears also in the GNOME code of conduct. KDE just had better google juice for the term :)