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