742594 - [Page Thumbnails] Large jank soon after switching tabs

Status: NEW

(Firefox :: General, defect)

Description

[(dormant account)]

We must be running some setTimeout()ed js after switching tabs, because I experience a 200-400ms pause a few hundred milliseconds after switching to a tab. This correlates with session-store + tab screenshoting(correlation does not equal blame)

340 ({FX_SESSION_RESTORE_COLLECT_DATA_MS:[[5, 1]], FX_SESSION_RESTORE_SERIALIZE_DATA_MS:[[3, 1]], GC_INCREMENTAL_DISABLED:[[0, 1]], GC_IS_COMPARTMENTAL:[[1, 1]], GC_MARK_MS:[[12, 1]], GC_MMU_50:[[4, 1]], GC_MS:[[17, 1]], GC_NON_INCREMENTAL:[[1, 1]], GC_REASON:[[5, 1]], GC_RESET:[[0, 1]], GC_SLICE_MS:[[17, 1]], GC_SWEEP_MS:[[12, 1]]})

Above shows a 300+ms jank, where session store took <10ms, GC took <40ms. There is a 100% correlation between this jank and above session-store telemetry activity, so I'm guessing the jank is trigger by some related javascript.

I can reproduce this on multiple windows machines, but not on Mac.

Comment 1

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

If it's tab that's already been loaded, then Session restore only does the following on TabSelect:
1. update an index
2. tell crash reporter to update it's current URL (possible that's doing something janky)

I don't think there are any setTimeouts in that path in sessionstore.

If the tab hasn't been restored then we do that, which does have some expected overhead associated with it.

Can you be more specific about which case it is?

https://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/src/nsSessionStore.js#1201

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

We're taking screenshots of tabs ~2 secs after they've been selected. So that really might be the culprit. Does the jank still occur when commenting out the following line?

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-thumbnails.js#57

Comment 3

[(dormant account)]

(In reply to Paul O'Shannessy [:zpao] from comment #1)
> If it's tab that's already been loaded, then Session restore only does the
> following on TabSelect:
> 1. update an index
> 2. tell crash reporter to update it's current URL (possible that's doing
> something janky)
> 
> I don't think there are any setTimeouts in that path in sessionstore.
> 
> If the tab hasn't been restored then we do that, which does have some
> expected overhead associated with it.
> 
> Can you be more specific about which case it is?

This after the session has been restored. Tim's suggestion sounds plausible. It could be a combination of network cache locking and screenshoting. I'll try commenting out that line.

Comment 4

[(dormant account)]

So I was going to try this, but there is no point. My i7 macbook air is probably triggering cache locking issues seen in http://dl.dropbox.com/u/5961467/moz/FX_THUMBNAILS_STORE_TIME_MS.png. Checkout my local histograms: http://dl.dropbox.com/u/5961467/moz/fx_thumbnails_local.png. Both capture time and storing time is terrible.

Comment 5

[(dormant account)]

I suspect a couple of things are inplay here
a) slow capture time
b) cache locking negating your async efforts while cache entry is written
c) doing capture AND write during the same setTimeout

Given how expensive drawWindow is, can we do some sort of exponential backoff for users who have slow machines(or don't ever click on thumbnails?)

Comment 6

[(dormant account)]

(In reply to Taras Glek (:taras) from comment #5)
> I suspect a couple of things are inplay here
> a) slow capture time
> b) cache locking negating your async efforts while cache entry is written
> c) doing capture AND write during the same setTimeout
> 

Looks c) is not a problem.

Comment 7

[(dormant account)]

P1 as this manifests rather nastily when switching tabs

Comment 8

[Justin Lebar (not reading bugmail)]

Whoops, sorry, wrong bug.