Closed Bug 716735 Opened 13 years ago Closed 9 years ago

CoverItLive chats lead to stuttering when live updates are turned on

Categories

(Core :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: RyanVM, Unassigned)

References

()

Details

(Whiteboard: [snappy:p3])

I was on a live chat on espn.com last night and found that when I had it open, the browser began to stutter badly (presumably due to GC/CC). about:memory didn't show anything out of the ordinary. To reproduce, open a live chat (see URL above) in a tab and make sure that it is updating live. Leave it open for awhile and you should see the browser begin to start pausing and stuttering periodically after awhile.
You'll also notice that the throbber spins indefinitely, but that's out of scope for this bug, I would think.
If you want to see if GC/CC are causing it, set javascript.options.mem.log to true, then go to tools -> web developer -> error console. That will print out a message when there is a CC or a GC. See if it corresponds to the stuttering you are seeing. There are a number of possible causes.
If it isn't either of those, we have a few other tools for jank-analysis that I don't know how to use.
We only have a few sample_label in right now. You'll need a local build and a bit of guessing to pin-point where the time is being spent. You can use an external profiler to find the hotspots to help with the guessing. Once you relevant sample_label in the samples during hangs will be labeled in red.
I think this is a case of us needing to throttle pages spinning in an xmlhttprequest loop
Depends on: 712478
Whiteboard: [Snappy] → [Snappy:p4]
I keep accidentally using a non-existent snappy:p4 priority
Whiteboard: [Snappy:p4] → [snappy:p3]
I've been running with a CoveritLive chat open for the last 15 minutes or so and don't see any noticeable slowdown.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.