Re: Massive speed improvement in GObject type checking code
- From: Owen Taylor <otaylor redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Erik Walthinsen <omega temple-baptist com>, gtk-list redhat com, Gtk+ Developers <gtk-devel-list gnome org>, gstreamer-devel lists sourceforge net
- Subject: Re: Massive speed improvement in GObject type checking code
- Date: 17 Jun 2001 08:32:43 -0400
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]