Re: Instance private data

[Owen Taylor <otaylor redhat com>]

On Thu, 2003-02-13 at 19:14, Tim Janik wrote:

> not quite, at least, there's a malicious assert and some cosmetics that should
> be changed, but before that, i have API concerns. allowing private struct
> size to be added only once per type, and only from class_init() seems
> reasonable to me, too. given that, the complexity can be reduced to gtype.c
> i think, simply by storing private_base in the type node as well, so
> we get:
> 
> /* 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))
> 
> or am i missing something in your patch?

I like the increased encapsulation and simplicity here. 

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.

But the potential order-of-magnitude performance difference
was my concern.

Regards, 
                                    Owen

Random Q: Why does g_type_class_peek_private() need a read lock?

(*) lookup_type_node_I looks like prime cmov terrority, but
    even compiling for i686, gcc-3.2/3.3 doesn't take advantage.
    Project for aspiring compiler hackers - find out why, and
    if fixing it makes a noticeable difference to GObject
    performance.