Closed Bug 1373058 Opened 8 years ago Closed 6 years ago

performance issue on Netflix DVD queue

Categories

(Core :: Layout, defect, P3)

56 Branch
defect

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
Component: Untriaged → Layout
Product: Firefox → Core
Depends on: 1373079
nsNativeThemeWin::GetWidgetBorder/GetMinimumWidgetSize seems to be very high on that list. I filed bug 1373079 on that.
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.
Attached image DVD_queue_saved.GIF
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!
Depends on: 1373095
(I filed bug 1373095 on making nsTableCellFrame::GetRowSpan() faster)
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.
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
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.)
Priority: -- → P3
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!
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!
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.

Attachment

General

Creator:
Created:
Updated:
Size: