After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 341380 - Optionally disable on_*() default signal handlers.
Optionally disable on_*() default signal handlers.
Status: RESOLVED FIXED
Product: glibmm
Classification: Bindings
Component: build
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2006-05-11 07:42 UTC by Murray Cumming
Modified: 2006-08-07 10:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
glibmm_disable_default_signal_handlers.patch (7.16 KB, patch)
2006-05-11 07:44 UTC, Murray Cumming
none Details | Review
gtkmm_disable_default_signal_handlers.patch (6.43 KB, patch)
2006-05-11 07:44 UTC, Murray Cumming
none Details | Review

Description Murray Cumming 2006-05-11 07:42:55 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
Comment 1 Murray Cumming 2006-05-11 07:44:10 UTC
Created attachment 65218 [details] [review]
glibmm_disable_default_signal_handlers.patch
Comment 2 Murray Cumming 2006-05-11 07:44:34 UTC
Created attachment 65219 [details] [review]
gtkmm_disable_default_signal_handlers.patch
Comment 3 Murray Cumming 2006-05-11 08:32:30 UTC
By the way, this reduces the libgtkmm .so code size by about 500K.
Comment 4 Murray Cumming 2006-05-11 09:20:24 UTC
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.
Comment 5 Paul Davis 2006-05-17 10:35:52 UTC
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.
Comment 6 Murray Cumming 2006-05-17 10:48:01 UTC
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.
Comment 7 Paul Davis 2006-05-17 10:57:22 UTC
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.
Comment 8 Murray Cumming 2006-05-17 11:20:09 UTC
Sorry, yes, they are in glibmm.
Comment 9 Murray Cumming 2006-08-07 10:44:15 UTC
I commited this to glibmm, along with necessary changes to gtkmm, in 2.6, 2.8, and 2.9/2.10.