==================== ms # ----- Event Loop: nsInputStreamReadyEvent 7119 11 ----- Input Events: nsInputStreamPump 7119 11 ----- Pump Events: thunk:nsNNTPProtocol::QueryInterface(...) 7119 11 ==================== ms # ----- Event Loop: nsInputStreamReadyEvent 6284 15 nsTimerEvent 242 123 ----- Timers: nsUITimerCallback 121 2 ----- Input Events: nsInputStreamPump 6284 15 ----- Pump Events: thunk:nsNNTPProtocol::QueryInterface(...) 6283 15
As of late, I’ve noticed that Thunderbird has been pegging one of my CPU cores periodically in ways not correlated with gloda activity, the usual scapegoat. With some enhancements to my systemtap script from last time, I can now see that it apparently takes something like 13 seconds of dominating the event loop to perform the check for new messages in my 26 subscribed news folders on news.mozilla.org. Yowch. At least this is on a debug build!
Changes are that we now cover input stream ready events, input pump listeners, and proxied objects (which lets us see what Thunderbird IMAP gets up to). Also, the output is more concise and only shows things that take at least 100ms of aggregate wall clock time.
Script invocation currently wants to look like this:
sudo stap -v moz-event-loop.stp /path/to/thunderbird/objdir/mozilla/dist/lib/libxpcom_core.so /path/to/thunderbird/objdir/mozilla/dist/bin/components/libnecko.so | ../addrsymfilt.py `pgrep thunderbird-bin`