Month: November 2010

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

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: http://live.gnome.org/Hackfests/GTK2010/RoadmapDiscussion

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.