Am 26.04.2012 20:32, schrieb Jasper St. Pierre: > OK. So I talked this over with a bunch of coworkers, and we had a lot > more ideas. (I've CC'd. Hopefully they can provide more insight than > what I talked about here) > > * First of all, Valgrind. There are two tools in valgrind that are useful: > memcheck - The one that everybody knows. It should detect any > leaks, but there are a lot of false positives. > massif - A heap profiler. It tracks every malloc by call stack > and groups like ones together, to give you a rough idea of where > memory is going. It may not work for JavaScript, as the call stack is > going to be the same for all GObjects created through gjs (object_new > => g_object_newv) > > Note that if you want to run Valgrind (or really any memory tool), > make sure to set the G_SLICE and G_DEBUG env vars correctly. See the > wiki page on Valgrind for more information[0]. > > * JS has a heap profiler. You can see it in more recent Firefox > builds at about:memory. This isn't in js185 AFAIK, so it's not > available to us. > > * JS has another heap profiler, at JS_DumpTree. It's disabled by > default in most builds (I don't know why). Can't use that. > > * SystemTap. We don't have SystemTap integration in the Shell yet > (although you don't really need it as it can parse debuginfo, but it's > more cumbersome). Here's an example SystemTap script from Colin that > tracks GObject counts by type: > > https://bugzilla.gnome.org/show_bug.cgi?id=614619#c2 > > [0] http://live.gnome.org/Valgrind >
Thanks, Jasper! That looks promising. I will check it out and see if I can successfully apply one of the mentioned tools. Regards Sven _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
