Re: Instance private data
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: Mark McLoughlin <mark skynet ie>, Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: Instance private data
- Date: Mon, 17 Feb 2003 21:50:53 +0100 (CET)
On 14 Feb 2003, Owen Taylor wrote:
> On Thu, 2003-02-13 at 19:14, Tim Janik wrote:
> > /* using g_class as argument is more convenient and conveys class_init()
> > * time like g_type_class_peek_parent()
> > */
> > void g_type_class_add_private (gpointer g_class,
> > guint16 priv_size);
> >
> > /* return ((guint8*) instance) + instance_size + priv_base(priv_type), where
> > * priv_base for priv_type is the sum of priv_size from its ancestors
> > */
> > gpointer g_type_instance_get_private (GTypeInstance *instance,
> > GType priv_type);
> >
> > /* macro to be used the same way as G_TYPE_INSTANCE_GET_CLASS() */
> > #define G_TYPE_INSTANCE_GET_PRIVATE(obj,type,ctype) ((ctype*) g_type_instance_get_private ((obj), type))
> >
> > results in example usage:
> > gtk_window_class_init (GtkWindowClass *class)
> > {
> > g_type_class_add_private (class, sizeof (GtkWindowPrivate));
> > }
> > #define GTK_WINDOW_GET_PRIVATE(obj) (G_TYPE_INSTANCE_GET_PRIVATE (obj, GTK_TYPE_WINDOW, GtkWindowPrivate))
> The main reason I didn't go with something like this initially was
> efficiency. With cast checking turned off, my scheme basically comes
> down to a couple of dereferences:
>
> object->class->private_base + private_offset
>
> Only slightly more expensive than object->priv. While
> g_type_instance_get_private() is going to be a lot more
> expensive - it involves a function call, and several
> invocations of lookup_type_node_I, each with a high probability
> branch prediction miss. (*)
>
> Does it matter? Perhaps in the overall scheme of GObject
> performance not. And where Mark's scheme can be used,
> it doesn't matter at all.
i don't think branch prediction misses have any significant impact
for this function. after all, most people will want to do
GtkWindowPrivate *priv = GTK_WINDOW_GET_PRIVATE (obj);
/* use priv */
anyway. and even if not, g_type_instance_get_private() involves
nothing more than two array dereferences and a couple additions,
we don't even need a read lock here (see below).
> But the potential order-of-magnitude performance difference
> was my concern.
the overhead of g_type_instance_get_private() is negligible compared
to what ordinary accessors would do.
> Regards,
> Owen
>
> Random Q: Why does g_type_class_peek_private() need a read lock?
assuming you meant g_type_class_peek_parent(), it should simply
have a read lock because it's accessing concurrently used data
(mechanic reasoning).
most of TypeData (TypeNode.data) remains constant as long as a
class or instance (implies class) of a type exists. so in situations
where existance of a class or instance can safely be assumed,
we don't in practice need a read lock to access constant portions
of TypeData.
for g_type_class_peek_parent(), parent->data->class.class is constant
as long as the derived class exists, and for g_type_instance_get_private(),
node->data->instance.priv_{size|base} will be constant as long as
instances exist. so we can actually turn the current read locks
into comments describing why they don't need to be acquired.
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]