GNOME Bugzilla – Bug 679835
gvariant format string parsing (and assertions) are expensive for high-performance applications
Last modified: 2012-08-27 20:53:52 UTC
So for better or worse (mostly better, but this bug is about the worse), I chose to use GVariant for implementing a userspace filesystem. For example: http://git.gnome.org/browse/ostree/tree/src/libostree/ostree-core.h?id=95921bcbf0a6b710dedd107fbacb41090af74ed9#n47 It turns out that the slowest part of my program (currently, after I've fixed various other things), is g_variant_type_string_scan(). Which in turn is called mostly from g_variant_get(). Which in turn is mostly hit when I do this: http://git.gnome.org/browse/ostree/tree/src/libostree/ostree-core.c?id=95921bcbf0a6b710dedd107fbacb41090af74ed9#n1011 That code gets run *a lot*, because, well, I have a lot of files. Now, I could probably avoid turning my file objects into GFileInfo, but if I want to use GVariant, I'm not aware of a faster way to parse them. I think what I'd like is something like: GVariantReader *g_variant_reader_new ("(uuuu&s@a(ayay))"); void g_variant_reader_get (reader, variant, &uid, &gid, &mode, &rdev, &symlink_target, &ret_xattrs); Possibly even nicer would be a way to build a relationship between C structures and certain GVariant formats. For example: typedef struct { guint32 uid; guint32 gid; ... GVariant *xattrs; } MyFileObject; MyFileObject mystruct; g_variant_reader_new ("(uuuu&s@a(ayay))", G_VARIANT_READER_STRUCTURE_BASIC); g_variant_reader_get (reader, variant, &mystruct);
Created attachment 218703 [details] perf report
It might be faster to use a GVariantIter or g_variant_get_child_value() followed by direct access with the appropriate getter -- you get to avoid format strings that way. See bug 544026 for some possibly interesting ideas with regards to fixing this issue in GLib...
http://git.gnome.org/browse/glib/commit/?id=7936af693477f5b8dfeef4e0d90e6fa4531cf395