Closed Bug 1210842 Opened 10 years ago Closed 7 years ago

hilton.com website is really slow / hogs CPU

Categories

(Web Compatibility :: Site Reports, defect, P3)

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 44
Platform:
x86_64
Windows 8.1
Type:
defect

Tracking

(Performance Impact:?, e10s+, firefox44 affected)

Status:
RESOLVED WORKSFORME
Project Flags:
Performance Impact ?
Tracking Flags:
Tracking Status
e10s + ---
firefox44 --- affected

People

(Reporter: vladan, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

zuh0wlVr.rar
873.53 KB, application/x-rar
Details
STR: 1. Visit http://hiltongardeninn3.hilton.com/en/hotels/ontario/hilton-garden-inn-toronto-downtown-YYZDTGI/index.html 2. Scroll the page top-to-bottom and bottom-to-top several times with the mousewheel 3. Open a new tab with https://bugzilla.mozilla.org/ 3. Quickly alternate between the tabs Notice how the spinner is visible during tab switches. The tab switch time in single process isn't snappy either, but I think it's noticeably better than e10s. Tested on Nightly 44 on Windows 8.1, on an HP i3 (content-perf laptop). See also bug 1210836
with/without e10s, this page continuously uses 100% of 1 CPU core.
Assignee: nobody → jmathies
Priority: -- → P1
(In reply to mayankleoboy1 from comment #1) > with/without e10s, this page continuously uses 100% of 1 CPU core. This can be the reason. During tab switch to get the the layers from the window of the targeted tab we need to process an event and if the content process is busy that can take a while so we show the spinner. I think that was not the case pre-e10s.
(In reply to (PTO Jan 4-10) Vladan Djeric (:vladan) -- please needinfo from comment #0) > Notice how the spinner is visible during tab switches. The tab switch time I can see the spinner on Linux as well. Grabbed a profile [1] and it shows there are heavy restyles for <html>, which delays the async tab swithing. I haven't traced how the switching is done yet, maybe PBrowser::RecvDeactivate() or RecvSetDocShellIsActive(). [1] https://cleopatra.io/#report=1db44e7fb447a9997e73aa386f44d92e508b8ab2
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #2) > This can be the reason. During tab switch to get the the layers from the > window of the targeted tab we need to process an event and if the content > process is busy that can take a while so we show the spinner. Shouldn't we set dom.ipc.processCount to a larger number (>1) when e10s is enabled?
(In reply to Ting-Yu Chou [:ting] from comment #3) > there are heavy restyles for <html>, which delays the async tab swithing. I > haven't traced how the switching is done yet, maybe > PBrowser::RecvDeactivate() or RecvSetDocShellIsActive(). It's done by setting docShellIsActive true when change tab state to loading: https://dxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#3231 which requires an IPC to the TabChild and could be handled later if the content process is busy.
Component: General → Untriaged
Component: Untriaged → Tabbed Browser
No, this still needs triage before being moved anywhere, including tabbed browser (or "general"). Long tab switch times are likely because the content process is 'stuck'. If the content process is stuck on a website, this is a bug in whatever code causes us to be stuck for that website, which likely has nothing to do with tabbed browser code (e.g. "more restyles when using e10s", from comment 4, would not be a tabbed browser issue).
Component: Tabbed Browser → Untriaged
Attached file zuh0wlVr.rar —
Profile Hopefully it helps STR: 1.Open the page mentioned in comment 0 2. Scroll with the mouse wheel up and down quickly 7-8 times Result: Nightly uses 100% of 1 core.
I lied. You dont have to scroll at all. Just opening the page uses CPU continuously.
Ok, just tested this with Chrome and Edge. In both these browsers, I see the same behaviour. Simply opening the tab in the foreground will use 100% CPU. In all the three browsers, if you open the URL in a background tab, it will use about 10% CPU.
Flags: needinfo?(gijskruitbosch+bugs)
From a quick look at the attached profile, it looks to me like comment #4 is correct and we spend a lot of time on the vsync timer doing reflows. :kats or :mats, could you take a look if there's something we can improve here? Jim, this is assigned to you, but it has been 8 months - I'm guessing you're not actively working on this? Clearing P1 because it's been 8 months so it seems unlikely that P1 is an accurate reflection of priority at this point.
Component: Untriaged → Layout
Flags: needinfo?(mats)
Flags: needinfo?(jmathies)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(bugmail)
Priority: P1 → --
Product: Firefox → Core
Assignee: jmathies → nobody
Flags: needinfo?(jmathies)
The performance here was bad under e10s and non-e10s so we didn't block the e10s rollout on it.
(In reply to Ting-Yu Chou [:ting] from comment #3) > Grabbed a profile [1] and it shows > there are heavy restyles for <html>, ... (In reply to mayankleoboy1 from comment #10) > Ok, just tested this with Chrome and Edge. > In both these browsers, I see the same behaviour. Simply opening the tab in > the foreground will use 100% CPU. Seems like the problem is in the content on the page to me.
Flags: needinfo?(mats)
What mats said, this seems like a bad website.
Flags: needinfo?(bugmail)
So, I guess we should move to tech evangelism? Do we have advice we can give the fine folks at hilton.com for writing better websites? :-)
Component: Layout → Desktop
Product: Core → Tech Evangelism
Summary: [e10s] Long tab-switch times on hilton.com website → hilton.com website is really slow / hogs CPU
Version: 44 Branch → Firefox 44
No longer blocks: e10s-perf
Hard to know if this issue reproduces for anyone anymore, but maybe someone doing flow triage can take a look.
Priority: -- → P3
Whiteboard: [qf]
cant repro this anymore on Win10x64 and latest nightly.
Mike Conley and Jean Gong tested this on MacOS. I tested on Linux. Cannot repro this. Resolving as WORKSFORME.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Web Compatibility
Performance Impact: --- → ?
Whiteboard: [qf]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: