more systemtap mozilla event loop awareness

Posted on by 
====================                                             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`

4 thoughts on “more systemtap mozilla event loop awareness”

  1. Would I be able to figure out why I get a beach-ball almost everytime I try to compose an email using your scripts (given that I would need to make them run on osx). ?

  2. If you’re beach-balling for an extended period of time, the OS X sampler, manual invocation of Shark, or the beachball detector instrument should all be more suitable (and require much less work to adapt than my fairly linux-biased scripts).

  3. Andrew, is it possibly bug 539194 that you are seeing with this “get new messages” stuff? We would be sooooo glad to get a clue of what’s up and how to fix it…

  4. The specific thing I’m seeing seems pretty easy to reproduce and quite lengthy; assuming others are experiencing the problem, they should be able to attach a debugger or run a profiler against it and get a good number of samples. If someone has trouble reproducing, I believe that for all of the newsgroups I downloaded the entire history and brought most of them fully offline.

Comments are closed.