Open Bug 1488435 Opened 2 years ago Updated 3 months ago
Significant key input delay when typing on large Google Docs
We experience a significant key input delay on both Nightly and Release for Google Docs. This issue is most prominent on large docs. To reproduce: Open a big Google Doc. Wait for it to be loaded completely. Start typing. The problem is more pronounced within the first 60-180sec after loading and will get less severe, but still perceivable afterwards. Here's a profile recorded to capture the issue on currently Nightly: https://perfht.ml/2NdbaCc
Just wanted to add that I was previously on the 2018-08-18 build of Nightly and it took 20-30s for the input delay to no longer be noticeable. However, on the latest nightly build 2018-09-04 it took around 45s.
Need some example Google Doc here. And the performance profile shows this is all JS.
(100's of ms of time to process key events, almost all spent in JS/ION/etc). In some cases near 500ms. It *seems* to be worse with the gecko profiler enabled -- and vchin indicates it regressed between 8/18 and now (though it wasn't wonderful then). Note edge and chrome are both very snappy here. This is a perf profile (with --enable-perf) of that. lots of JS/ION stuff, lots of JS Helper action Content Mainthread perf profile: https://perfht.ml/2Q5Iz0g Random JS Helper (nearly 200ms): https://perfht.ml/2Q5uZtS mostly in FlagAllOperandsAsHavingRemovedUses (it's compiling..) This is a Gecko Profiler look at it: https://perfht.ml/2Q5YBHw with 125-250ms keypress events and 500-1s+ event processing delays Note that it *seems* that Gecko Profiler on makes it worse. Not 100% confirmed.
Finding the regression range should be always the first step in regression bugs.
Depends on: 1375631
I see a few InstanceOf on unboxed objects that cannot attach ICs. We are planning to remove the unboxed object mechanism though.
(In reply to Olli Pettay [:smaug] from comment #5) > Finding the regression range should be always the first step in regression > bugs. I tried to roll back to a previous build of Nightly and can't reproduce the good behavior anymore. So it may not be a recent regression after all.
I suspect this is a code or build change on their end.
(In reply to Ted Campbell [:tcampbell] from comment #8) > I suspect this is a code or build change on their end. If we have specific questions about this, we can ask Steve Saviano (he's responsive here on Bugzilla).
(In reply to Ted Campbell [:tcampbell] from comment #8) > I suspect this is a code or build change on their end. Steve, are you aware of any changes leading to this input delay? We notice input delays on Chrome as well.
Hmm, could be one larger item. Will investigate on Docs-side and report back.
I noticed some long GC slices marking weak references when profiling this, so making bug 1167452 a dependency.
Depends on: 1167452
Is there a sample doc that could be shared? (view only is fine and I can make a copy)
External doc with nothing sensitive(first few pages repeated about 50 times - ~147 pages): https://docs.google.com/document/d/1CBF65WS71QOC4XiUH-KT2ZGDTp5ieSMSqC-d1NfoFCw/edit#
CCing Bruce Dawson because it's possible he'd be interested (though this isn't Windows-specific)
Thanks Randell for sharing the doc! Agree this feels slow (not just in Firefox btw). We're investigating on our end to see what we can improve.
I'm pretty sure this is a dup of bug 1478104. The patch there fixes the issue for (DRASTICALLY improves the experience). I don't want to close as dup unilaterally though.
To clarify my comment: bug 1478104 identifies the same issue on the same doc, and the patch fixes the issue.
We have a doc in this bug that's visible to externals, so we should use that as our "example" case to point to if we dup (and move over the dependent bugs we attached to this one). Or perhaps better, rename the other one about JIT tuning, and make it one of the dependencies of this bug. It doesn't matter much so long as we don't lose track of any of the ideas/bugs here. I did a quick measurement of this with the patch from bug 1478104. keypress events that were 125-250+ms (and some near 500ms) are now ~50-90ms (most 55-65 or 70), which is a 2-3x improvement. We're still maybe 50% slower than Chrome, but we had been 150-400% slower.
You need to log in before you can comment on or make changes to this bug.