633733 - Switching to tab showing github source view is very laggy

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[Josh Matthews [:jdm]]

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.

Comment 1

[Josh Matthews [:jdm]]

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.

Comment 2

[Josh Matthews [:jdm]]

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.

Comment 3

[Josh Matthews [:jdm]]

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.

Comment 4

[Josh Matthews [:jdm]]

Hmm, we also do spend 1.55% of time under js_GC.

Comment 5

[Alice0775 White]

laggy scrolling, High CPU usage when clicking and scrolling .
https://github.com/zixaphir/AppChan/blob/master/options.css