On Wed, 4 Jun 2008 10:56:56 +0200 (CEST)
Tim Janik <timj imendio com> wrote:
> On Tue, 3 Jun 2008, Jean-Yves Lefort wrote:
>
> > On Tue, 3 Jun 2008 13:34:13 +0200
> > Kristian Rietveld <kris imendio com> wrote:
> >
> >> 4. We will completely lose all means to simply access fields by just
> >> dereferencing the structure. Instead, we will start to use GObject
> >> properties to access this data much more often. Using g_object_[sg]et()
> >> can become a little tedious. Therefore we should introduce a couple of
> >> convenience accessors for GObject properties such as g_object_get_int(),
> >> *double(), *string(), etc.
> >
> > Because of the dynamic nature of the GObject property system, this
> > would also bring a substantial performance overhead,
>
> No, it won't. Simply because the vast majority of widget field accesses
> are not time critical. E.g. reading out GTK_LABEL (widget)->text is something
> that rarely happens more than once or twice per X event being processed.
> So it really doesn't matter whether you use a field access here, a
> simple getter function, a dynamic property accessor or a signal emission
> to figure the value.
>
> We have only a few cases, where performant field accees is desired, e.g.:
> GtkWidget *toplevel = widget;
> while (toplevel->parent)
> toplevel = toplevel->parent;
> For such cases, where additional overhead could actually show up in the
> profiles, we are providing helper functions, see gtk_widget_get_toplevel().
>
> > Note that I don't propose to abandon the dynamic access functionality,
> > which is certainly useful and desirable in a number of specific
> > situations. I simply point out that the performance penalty of dynamic
> > access is unjustified for static use.
>
> Note that most often you can use very simple and fast getter functions
> instead of the dynamic proeprty interface:
> G_CONST_RETURN gchar *
> gtk_label_get_text (GtkLabel *label)
> {
> g_return_val_if_fail (GTK_IS_LABEL (label), NULL);
> return label->text;
> }
>
> Other than that, I'd have to see reproducable performance profiles for
> things claimed to be "unjustifyably" slow, to consider changes/fixes.
I thought that GObject was meant as a general-purpose object system
for C, rather than as a GTK+-specific utility library. I suppose I
misunderstood.
--
Jean-Yves Lefort <jylefort brutele be>
Attachment:
pgpAzXq5cgc0O.pgp
Description: PGP signature