Signal performance tuning

[Alex Larsson <alexl redhat com>]

I've added some profiling code to gsignal to find out a bit about what's
happening during normal gtk+ usage. All the tests were done byt fooling
aroung in testgtk doing "normal" stuff, like resizeing, opening tests,
using tests. Clicking buttons etc.

Some interesting stats:
a) About 97% of all signal emissions result in no (non-default) signal
   handler being called.
b) When the crack-smoking default handler for "notify" is removed, 80% of
   all signal emissions actually call a default handler for for the
   signal.
c) 20% of all emissions are "notify"
d) There are about 9% more emissions of "notify" than
   "properties_changed".
e) If i remove all emissions of "properties_changed" and instead emit the
  "notify" signal directly, 55% of all emisssions have a default handler.

Some interestion conclusions here.

c) tells me that we emit a lot of notify signals, this could be costly.

d) tells me that the grouping function of properties_changed doesn't give
any huge advantage, especially compared to the cost of emitting two
signals instead of one. This, and the fact that probably very few people
will use the properties_change signal tells me that if that signal isn't
very cheap we should probably get rid of it.

a) + e) Means that if we remove the properties_changed signal we can avoid
doing a lot of work (even argument marshalling) for nearly 50% of the
emitted signals by bailing out early in g_signal_emit. This would save a
lot of time. Of course, we have to be able to quickly check that 1) there
are no handlers, 2) the class closure will not call any handler, and 3)
there are no signal emission hooks. Currently checking the class closure
would be kinda hackish, but the other ones should be pretty easy.

So, basically, I suggest removing the properties_changed signal, and
adding some kind of check to a closure to quickly test if it actually
would call a handler.

Ideas?

/ Alex