On 10 February 2013 15:22, Emmanuele Bassi <eba...@gmail.com> wrote:

> On 10 February 2013 13:57, Ross Lagerwall <rosslagerw...@gmail.com> wrote:
> > On Sun, Feb 10, 2013 at 11:08:31AM +0000, Emmanuele Bassi wrote:
> >> disabling cast checks is usually the result of performance profiling,
> >> tho, so it should only be used if you have profiled your application
> >> code and verified that type casting is high on the profiles; there are
> >> also various ways to avoid that, by using ancillary values and the
> >> correct type to minimize casting, before a blanket type cast check
> >> disable.
> >>
> >
> > What are ancillary values, and how can you use them to minimize casting?
>
> if you are calling multiple functions of the same type, e.g.
>
>   gtk_widget_set_foo (GTK_WIDGET (w), foo);
>   gtk_widget_set_bar (GTK_WIDGET (w), bar);
>   gtk_widget_set_baz (GTK_WIDGET (w), baz);
>
> instead of using a checked cast for each call, use an ancillary
> variable and cast once:
>
>   GtkWidget *tmp = GTK_WIDGET (w);
>   gtk_widget_set_foo (tmp, foo);
>   gtk_widget_set_bar (tmp, bar);
>   gtk_widget_set_baz (tmp, baz);
>
> there's also the option of using the most common type when calling
> functions or inside signal handlers, to minimize type checks; if you
> have a function that calls method of the same type, use that type as
> part of the arguments, instead of doing a cast (upwards or downwards).
>
>
In support of Emmanuele's reasoning - I've seen a few places where dynamic
type checking did induce a significant cost. Fx. a tight loop with many
iterations. In all cases I've been able to fully solve this by simply
moving the casts to strategic places.

One common way is to make sure that calls to private methods inside the
same compilation unit does not do type checks. These can easily be ensured
around the public access points.

So before recompiling glib, or maybe even before you bother profiling this
- if you can do a trivial refactoring to reduce the type checks I'd
definitely go for that in order to save yourself time.

Cheers,
Mikkel
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to