Closed
Bug 1373058
Opened 8 years ago
Closed 6 years ago
performance issue on Netflix DVD queue
Categories
(Core :: Layout, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox57 | --- | wontfix |
People
(Reporter: Mark12547, Unassigned)
References
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36
Steps to reproduce:
This requires a Netflix DVD plan. Have a long Netflix DVD queue (6 at home, 479 queued, 107 saved). Log on to https://dvd.netflix.com then click on "Queue 479" on the top border. This will go to https://dvd.netflix.com/Queue?qtype=DD to load the Netflix DVD queue.
Actual results:
Underperforms Chrome:
In Firefox Nightly 56.0a1 (2017-06-14) (64-bit) under Windows 7 Home Premium SP1 (64-bit), and in Firefox 54.0 (64-bit), both with new profiles, this takes too long:
48 sec (ave) under Firefox Nightly 56.0a1
54 sec (ave) under Firefox 54
31 sec (ave) under Google Chrome 59.0.3071.86 (Official Build) (64-bit)
Expected results:
I expected Firefox load times to be on par with Chrome. Instead, it took over 60% longer than Chrome.
Additional information:
Performance profile under Nightly captured as https://perfht.ml/2rxgiSM
A search turned up this bug on the same page, but after the page had loaded. My hunch is that it is possibly related: https://bugzilla.mozilla.org/show_bug.cgi?id=1243659
Updated•8 years ago
|
Component: Untriaged → Layout
Product: Firefox → Core
Comment 1•8 years ago
|
||
nsNativeThemeWin::GetWidgetBorder/GetMinimumWidgetSize seems to be very high
on that list. I filed bug 1373079 on that.
Comment 2•8 years ago
|
||
nsContainerFrame::PositionChildViews is also seems surprisingly high.
Surprising because it's gated by a frame bit:
http://searchfox.org/mozilla-central/rev/c49a70b53f67dd5550eec8a08793805f2aca8d42/layout/generic/nsContainerFrame.cpp#1001
which is typically false, since we don't have many frame types
that uses views. <iframe> and <select size=1> are the most common.
It would useful to know what the content looks like for that DVD queue,
in general terms.
I have added three screen shots for different sections of my queue, including the buttons that appear at a mouse waver. (The discs in the middle section can be moved both by hitting the button and putting in a number, and by using the mouse to drag an entry up or down in the queue.)
If you need more info, please let me know.
Thank you!
Comment 6•8 years ago
|
||
(I filed bug 1373095 on making nsTableCellFrame::GetRowSpan() faster)
Comment 7•8 years ago
|
||
Thanks for the screenshots. I'm guessing those "Blu-ray" with a chevron beside it
are indeed <select> elements, which would explain those PositionChildViews calls.
Still, a list with 500 or so is peanuts, we should render that extremely fast.
So I suspect the root cause of this problem is in Netflix's code, given that
it takes 31 seconds in Chrome too. That's insanely slow!
Looking around some more in the perf log shows a lot of reflows coming from
a JS "initCustomSelectBoxes" function which asks for an element's offsetHeight
(or offsetWidth), which triggers a sync reflow. Doing many of those is
probably what makes the page slow.
Mark, since you're a customer, you might want to report this through their
support channels too.
Yes, the "Blu-ray" with a chevron (and also "DVD" with a chevron) are for titles for which Netflix has that title in both disc formats, allowing me to select the other format. (That's useful if there is a long wait for one format but the other format is readily available.)
I'm trying to find a way to contact Netflix by some way other than by phone. So far I haven't found a spot to leave feedback on the website but I haven't given up yet.
Comment 9•8 years ago
|
||
Mats, Mozilla has a Netflix test account. Just let me know if you need access to profile the site.
btw, I was the person who filed that other "Netflix DVD queue is slow" bug 1243659 (last year). :) There was some analysis in that bug that pointed to performance problems with jQuery UI's dragging support or to slow layout recalculations. Also, the dragging delay appears to increase O(n) or worse with the length of the DVD queue in Firefox, suggesting we might be using an inefficient algorithm somewhere and not just "slow code".
See Also: → 1243659
Comment 10•8 years ago
|
||
Well, we're in the same order of magnitude as Chrome, which suggests
the problem is in Netflix' code. Loading a list of 500 or so DVD
titles shouldn't take 30-50 seconds, so clearly they're doing
something horribly wrong. I doubt there's anything we (or Chrome)
can do to make the load time of this page acceptable.
(Fwiw, I think bug 1243659 is a different matter, because there
Chrome has good performance and we're not.)
Updated•8 years ago
|
Priority: -- → P3
Updated•7 years ago
|
status-firefox57:
--- → wontfix
Reporter | ||
Comment 11•7 years ago
|
||
However, you (the developers) _have_ made good progress! What started as 54 seconds under Firefox 54 when I opened this Bug is now 35 seconds under Nightly 57.0a1 (2017-09-20) (64-bit), a 35% improvement! That is within 4 seconds of Chrome!
Thank you!
And with e10s-multi with a high enough dom.ipc.processCount, none of the other tabs are bothered when my overly-large Netflix DVD queue loads in a tab!
Thank you!
Reporter | ||
Comment 12•6 years ago
|
||
You have my permission to close this Bug.
(In reply to Mats Palmgren (:mats) from comment #10)
> ... which suggests the problem is in Netflix' code.
Netflix has rewritten the DVD Queue page, so now my overly-long Netflix DVD Queue (5 home + 496 queued + 44 saved) took between 4 and 5 seconds to load. Between the DVD Queue page rewrite, and you Developers optimizing Firefox, and a new computer (faster CPU), the net result is quite good for such a complicated page!
Again, Thank you!
Comment 13•6 years ago
|
||
Thanks for the update, Mark!
I'm glad the experience has gotten better, whichever way it ended up happening. :)
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•