With a few pages open including the one in the URL, I see vastly different tab switching behaviour. Specifically, flipping between any tab with ctr+tab is an instantaneous affair, except for the github one. Switching to that one, there's a very visible delay (up to a second, I believe) before the tab bar updates and the content repaints, and the browser is unresponsive until that happens.
Hmm, looks like a whole bunch of time is being dedicated to CSS rules processing on page load, at least. sysprof shows SelectorMatchesTree taking 22.4% of cumulative time in one context, and 4.56% in another.
Granted, I later discovered that I couldn't reproduce the problem with more tabs open, so I opened up https://github.com/wowus/pipe/blob/master/pipe.c#L825 and https://github.com/wowus/pipe/blob/master/pipe.c#L717 as well. At first, switching was instantaneous, but within 30 seconds I was receiving those huge delays again.
It looks like if I just keep switching tabs, I can reproduce this behaviour in a fairly short period of time. sysprof shows SelectorMatchesTree taking 19.18% cumulative time (RuleProcessorData::IsLink 6.44%, SelectorMatches 6.13%), all coming from nsWindow::OnExposeEvent which ends up in PresShell::WillPaint. I see a similar tree from nsSynthMouseMoveEvent::Run, which processes restyles and ends up spending 11.59% in SelectorMatchesTree (IsLink 4%, SelectorMatches 3.73%). I have the profile saved, so I can give more specific information if required.
Hmm, we also do spend 1.55% of time under js_GC.
laggy scrolling, High CPU usage when clicking and scrolling . https://github.com/zixaphir/AppChan/blob/master/options.css