Re: Massive speed improvement in GObject type checking code



Tim Janik <timj gtk org> writes:

> On Sat, 16 Jun 2001, Erik Walthinsen wrote:
> 
> > Parapraxis found that this reduced the number of calls in his code from
> > 10489576 to 1391, or a 99.987% reduction.  The total CPU time taken by
> > g_type_instance_is_a went from 26% to *not measurable*.
> 
> ok, that is quite alarming indeed.
> 
> >  This won't be
> > quite as dramatic in something like a Gtk+ application, where more checks
> > will be done between an object and one of its parent classes, but I would
> > still expect *at least* a 50% reduction.
> 
> i'd second that.

I'm not sure I would. When I did profiling for GtkObject, a huge
number of checks were from gtk_object_ref(), gtk_signal_emit()
and such, so the really big win was:

#define GTK_IS_OBJECT_CLASS(klass)      ( \
  (klass) != NULL && \
  GTK_FUNDAMENTAL_TYPE (((GtkObjectClass*) (klass))->type) == GTK_TYPE_OBJECT \
)

Of course, GDK and Pango have flatter inheritance trees than GTK+,
so, checking against the object type is probably a lot more
common than it used to be. 

But trying to second guess this is completely pointless. Someone
needs to add a few lines of instrumentation, run testgtk and
report the results.

> > Parapraxis wondered if multithreading has any impact on this, and I
> > believe it does not.  The object is not capable of changing its type,
> > ever, afaik.  The GType being compared will almost always come from a
> > _get_type() function that also cannot ever change the GType value.  The
> > only reason for the READER_LOCK in g_type_instance_is_a() is to avoid
> > someone else mangling the GLists that are walked through to find the
> > TypeNode in question, afaict.
> 
> mostly right. though, using g_type_instance_is_a() has another advantage,
> e.g. consider:
> 
> #define ID_NOT_IN_TYPE_SYSTEM	(255)
> static guint  id = ID_NOT_IN_TYPE_SYSTEM;
> static guint *id_p = &id;
> {
>   /*your version*/_G_TYPE_CIT (&ip_p, ID_NOT_IN_TYPE_SYSTEM); /* succeeds */
>   g_type_instance_is_a (&ip_p, ID_NOT_IN_TYPE_SYSTEM); /* fails,
>                                                    ID_NOT_IN_TYPE_SYSTEM is not
>                                                    registered */
> }

This (to me) completely doesn't matter. g_type_instance_is_a()
is virtually always called through BLAH_IS_FOO(), and in that
case, the ID is going to be in the type system.

> however, considering the speed advatage you report, it might be worth
> lessening the guarantees that G_TYPE_CHECK_INSTANCE_TYPE() makes, so that,
> for the supposedly pathological case that the instance is broken in that
> its class contains a non-registered type-id, _and_ this non-registered
> type id is being checked for, it returns a false TRUE.
> 
> we still need to get around the double evaluation of the (ip) arg of
> _G_TYPE_CIT() though, so we'd have to implement it via an auxillary
> static inline function.
> the same kind of optimization can be implemented for the class
> type-checking macro btw.

It's interesting to note that macros such as GTK_OBJECT() have double
evaluated for a long time, and nobody has ever noticed/complained.

Regards,
                                        Owen




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]