[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: How to use Quarks?
- From: Yu Feng <rainwoodman gmail com>
- To: Andrew Cowie <andrew operationaldynamics com>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: How to use Quarks?
- Date: Mon, 05 Jan 2009 10:28:22 -0500
On Mon, 2009-01-05 at 18:43 +1100, Andrew Cowie wrote:
> 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.
>
GData internally use GQuark. If you pass a string to g_object_set_data
as the key, GData first convert the string to a quark. In that sense
using set_qdata never gives you any performance penalty.
Unless you have a sea of keys, I don't think switching string to quark
will make a lot of difference. Perhaps you want to do some benchmarking?
Regards,
Yu
> AfC
> Sydney
>
>
> --=-Hr2f2rH2nOIXiN+iwLtT--
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]