Re: Less locking in gtype.c
- From: Alex Larsson <alexl redhat com>
- To: <gtk-devel-list gnome org>
- Cc: <timj gtk org>
- Subject: Re: Less locking in gtype.c
- Date: Thu, 6 Sep 2001 17:31:11 -0400 (EDT)
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]