Re: Less locking in gtype.c



On Wed, 5 Sep 2001, Alex Larsson wrote:

> Here is a patch that removes a lot of the locking in gtype.c. In a (very) 
> unscientific test it sped up G_TYPE_CHECK_INSTANCE_TYPE by about 150%.

We discussed this approach to some length on irc yesterday, and it really 
comes down to this: Changing GType to be gsize may silently break code 
that stores GTypes in guints on 64 bit architectures.

One possible way out would be to define GType to actually be gpointer, 
therefore giving warnings for broken code. This unfortunately does not 
work though, as you cannot switch on pointers.

We also came up with the idea to test the current breakage of e.g. the 
GIMP by making GType guint64 and see what breaks. I did this, adding some 
extra data in the upper 32 bit, and asserting in gtype.c if this wasn't 
there.

I started out by removing all instances of uint from
find -name "*.c" | xargs grep -C2 _get_type
in gimp. This fixed all the problems. Gimp ran happily.
The only problem i had was crashes in gtk+, so i fixed all the uint in the 
grep output in gtk+ too. 

The problems i found were:

One gimp plugin had three cases of:
guint 
message_window_get_type (void)
{
  static guint mw_type = 0;

Gimp proper had 8 cases, and gtk+ had 5 cases of:
GtkType
gimp_channel_list_view_get_type (void)
{
  static guint view_type = 0;

Jonathan fixed the same sort of problems in libgnomeui yesterday. It was a 
10 minute fix.

In summary, i think going to gsize for GType is feasible, since finding 
the problems that need fixing is pretty trivial (it even gives warnings 
on 64bit architectures), and fixing them are even more trivial.

In the end, it will cause us some more 64bit breakage initially, but i 
think the performance gain is worth it.

/ Alex








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