1597817 - Page load slows down UI interactions on certain old Linux machines

Status: RESOLVED INVALID

(Core :: Performance: Responsiveness, enhancement)

Description

[Wellington Torrejais da Silva]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

Suggestions...

• Have a old computer or device with limited hardware resources.
• Try to use a browser with more than one tab or with multimedia
• Slow to manipulate the browser interface when page loading

Actual results:

• Slow to scroll
• Slow to change between tabs
• Browser slow than Google Chrome to respond to cursor click in graphical interface

Expected results:

• Separate browser modal in different process or thread
• Make interface reaction fast
• Make fast to scroll page or switch tabs
• Prioritize mouse actions like close page or switch

Something like this.

Thanks!

Comment 1

[Daniel Bodea [:danibodea]]

I've set this enhancement bug's component as (Core) Performance.
Thank you for your contribution!

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Here's a graph of the responsiveness metric for the Talos tp5o benchmark:

https://treeherder.mozilla.org/perf.html#/graphs?highlightAlerts=1&series=mozilla-central,1647839,1,1&series=mozilla-central,1538194,1,1&timerange=31536000

It does appear that we've got a slow but steady decline in responsiveness here. This test works by sending tracer events through the main process's event loop, and measuring lag in servicing those tracer events.

The suggestions in comment 0 are good, and we're already doing them in some cases:

1. We have reference hardware that more closely matches consumer hardware that might be considered "older" or "weaker"
2. We split the content into its own process, so if the page load is having an impact on main process responsiveness, then it's likely that a side-effect of the load is starving the main thread (or the compositor thread) for CPU time.

Wellington Torrejais da Silva, could you tell us more about the machine you were testing on? Perhaps could you post your about:support? Could you also tell us which pages you were using to load test?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

ni?ing the reporter for comment 2.

Comment 4

[Wellington Torrejais da Silva]

Attachment: About-support-raw-data

Comment 5

[Wellington Torrejais da Silva]

Attachment: hardinfo_report4.html

Attached my hardware info.

Thanks!

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Hi Wellington,

Sorry for the delay - winter holidays have now concluded. Thanks for the report. Can you please supply the text from your about:support, rather than the JSON blog? (Choose the "Copy Text to Clipboard" button).

Comment 7

[Wellington Torrejais da Silva]

Attachment: MyAboutSupport

(In reply to Mike Conley (:mconley) (:⚙️) (Catching up on needinfos) from comment #6)
> Hi Wellington,
> 
> Sorry for the delay - winter holidays have now concluded. Thanks for the report. Can you please supply the text from your about:support, rather than the JSON blog? (Choose the "Copy Text to Clipboard" button).

Comment 8

[Wellington Torrejais da Silva]

Hi,

I've attached the about:support info.

Just only a comment, frequently I use many other tools, because I'm a Web Developer.
In most part of the time the machine isn't idle, there is a certain machine load.

But I'm still believe in that type of optimization suggested in this thread.
Maybe improve the performance to other users too.

Thanks!

Comment 9

[Mike Conley (:mconley) (:⚙️)]

So upon reflection, I think I'm going to close this bug as INVALID. We are testing on older hardware (the 2017 and 2018 reference hardware was expressly chosen because it was a more accurate reflection of end-user hardware). We're slowly ramping up the kinds of tests that we can run on the reference hardware in automation.

I don't think this bug is adding anything additional to the work already underway to get the reference hardware stood up.

Thanks, Wellington!