GNOME Bugzilla – Bug 341380
Optionally disable on_*() default signal handlers.
Last modified: 2006-08-07 10:44:39 UTC
There is a huge code size gain to be made by removing default signal handlers, such as Gtk::Button::on_clicked(). The problem is that they are virtual methods, so we have to pay for them even if we don't use them. We must pay for them in - code size: That's a lot of symbols in libgtkmm, and the symbols must be listed in applications that use libgtkmm. - load time: the symbols must be resolved by applications that use libgtkmm. Gtk::Widget has about 60 signals, so that's at least 60 virtual methods for each widget. As far as I can tell, this increases the code size of each derived class, even if a derived-of-derived class, maybe due to multiple inheritance. I have not yet committed this configure option to cvs, because this is the most disruptive option. Overriding virtual methods, instead of connecting signals, is quite convenient, but I don't think it's worth the cost on an embedded plat
Created attachment 65218 [details] [review] glibmm_disable_default_signal_handlers.patch
Created attachment 65219 [details] [review] gtkmm_disable_default_signal_handlers.patch
By the way, this reduces the libgtkmm .so code size by about 500K.
One of the disadvantages of applying this would be that we'd need some rather more intrusive #ifdefing in some examples than we need for the other --enable-api-* optoins. That would make them confusing for beginners.
Would it be against the rules to add a ./configure option to the effect of: --disable-virtual-signals to the configure scripts? Have it default to false so that beginners aren't confused why a function doesn't exist when all the docs say it does.
0. This patch would indeed add --disable-api-default-signal-handlers (auto* adds a --disable as well as --enable for each option.) 1. configure options are irrelevant to most coders. They use the distro packages, which use the defaults. This option would be for embedded use. 2. It wouldn't be against the rules. I already added --disable-api-vfuncs and --disable-api-properties. Maybe you are talking about hiding the API in the headers, but still building it in the library. We can't do that because a) these are vfuncs, and we would then be lying about the true object instance sizes, and b) the point of this is to reduce code size.
0. Cool. At one time I started playing with configure scripts, but then I found scons so I only know enough to get me by. 1. Yeah, point being, people who don't care enough to compile their own (I assume embedded systems require a build) don't get the benefit of removing the vfuncs. 2. I don't see them in gtkmm. I do see them in glibmm now though, but I wasn't really looking there. No, I'm talking about the same thing you are, just didn't see the options in the gtkmm configure script.
Sorry, yes, they are in glibmm.
I commited this to glibmm, along with necessary changes to gtkmm, in 2.6, 2.8, and 2.9/2.10.