Andrew Cowie schrieb: > On Sat, 2009-01-03 at 10:40 -0500, Yu Feng wrote: >> If you are accessing data member(g_object_set_data) frequently you could >> use quarks to accelerate the looking up process(g_object_set_qdata). > > On Sun, 2009-01-04 at 14:41 +0200, Stefan Kost wrote: >> If you use a hashtable with strings as keys, a lookup on the hashtable would >> need to compare the strings to find the entry. ... [so GQuark] as keys >> in the hashtable [is easier] > > This all begs a question: > > Is using g_object_set_qdata() and g_object_get_qdata() better because > the "arbitrary data" capability in GObjects is > > - powered by a mechanism that is going to convert string keys to > GQuarks (interning, presumably) every time for lookups, or > > - because it keeps two tables (one of string keys and one of > integer [GQuark] keys, or > > - ...? > > ie, it sounds like we should switch to g_object_set_qdata() for our one > and only use of GObject "data"; we request and set that value a *lot*, > and I'm always pleased to use faster code paths. The key we use is > already a static string anyway. > > AfC > Sydney > The point is that if you can do the g_quark_from_string() and store the quark, you can save the cost of this call. So if you need to lookup some struct for a parameter already, stick the quark in there and use qdata.
Stefan _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
