GNOME Bugzilla – Bug 710723
Main loop debug patches
Last modified: 2016-06-16 16:17:25 UTC
.
Created attachment 257916 [details] [review] gmain: Print debug of the source timeout calculations This is useful when hunting for small timeouts to reduce wake-ups.
Created attachment 257917 [details] [review] Enable main loop debugging by default It's hidden behind an envvar, and as such should have minimal impact on performance. It's already enabled by default on Windows (I guess to debug its internals, rather than for application developers).
*** Bug 710721 has been marked as a duplicate of this bug. ***
Created attachment 257978 [details] [review] Enable main loop debugging by default It's hidden behind an envvar, and as such should have minimal impact on performance. It's already enabled by default on Windows (I guess to debug its internals, rather than for application developers).
How about doing this with systemtap instead ?
Created attachment 258018 [details] [review] gmain: Print debug of the source timeout calculations This is useful when hunting for small timeouts to reduce wake-ups.
Review of attachment 258018 [details] [review]: The systemtap-based approach is a lot more powerful; one can write scripts which consume/print the data in whatever format, and even better unify it with other data like malloc/free. You can even start doing it *dynamically* while the system is running, without restarting everything to set an environment variable. Then when you're done collecting, you just turn it off. This patch is tiny enough on top of the other one though I'm not going to complain if you really want to land it. But just having it in Bugzilla and having a few core developers apply it locally and run it might work just as well.
Review of attachment 258018 [details] [review]: I agree, more or less.
systemtap also isn't upstream (is it in Ubuntu's kernel?), and there's no documentation in the GLib docs on how to enable systemtap for GLib applications. Matthias also had trouble making it use his jhbuilt GTK+ (as opposed to the system installed one), so those changes are not all in vain.
(In reply to comment #9) > systemtap also isn't upstream True...and if you look why it's not (unwinding DWARF in kernel space) I have to kind of agree with Linus =/ There are at least plans systemtap side to do more of the heavy lifting in userspace, but it's really complex to do while maintaining the full scripting power. > and there's no > documentation in the GLib docs on how to enable systemtap for GLib > applications. Matthias should be able to help since he did it more recently, but I can too. > Matthias also had trouble making it use his jhbuilt GTK+ (as opposed to the > system installed one), so those changes are not all in vain. Right...no, they're not but I guess all I wanted was "I tried systemtap and it didn't work" or something =)
FWIW http://blog.verbum.org/2011/03/19/analyzing-memory-use-with-systemtap/ still works here on RHEL7.0 beta machine. I just ran: $ stap -v -c gtk-demo ./glib-memtrace2.stp
Bug #759813 just added a load more SystemTap trace points to GLib, especially around the main context and GSources; I agree with Colin that stap is a more powerful approach. See also Dunfell (https://github.com/pwithnall/dunfell) which aims to make this easy to use for profiling. A command line client is on the TODO list.
And given that this has sat untouched since 2013, I think I'll take the liberty of closing it as wontfix. Please reopen if you disagree. :-)