[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: How to use Quarks?
- From: Stefan Kost <ensonic hora-obscura de>
- To: Andrew Cowie <andrew operationaldynamics com>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: How to use Quarks?
- Date: Mon, 12 Jan 2009 00:32:57 +0200
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
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]