1318178 - Bad performance on YouTube

Status: RESOLVED INVALID

(Core :: Audio/Video: Playback, defect)

Description

[sworddragon2]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160928160550

Steps to reproduce:

1. For example open this video: https://www.youtube.com/watch?v=kHrS5jZGwFI
2. While the video plays hover over it and unhover it again and repeat this multiple times if needed.


Actual results:

The player controls need around a second to appear/disappear on hovering/unhovering the video (in my case based on an AMD Phenom II X6 1045T @ 2.7 GHz).


Expected results:

The player controls should react immediately.


Additional information:

I'm having performance issues on YouTube since some time (I don't remember anymore how long they exactly exist - maybe over 1 year). These performance issues even appear if no web console is opened (so this issue is different from bug #1252012 ). In a Windows 10 VM Google Chrome reacts immediately with the STR. On making a look at this I have noticed that small mouse movements on an empty area need huge amounts of cpu time (on my Linux host around 200% of 600% cpu time are used). Comparing this in the Windows 10 VM with Firefox and Google Chrome Firefox needs around 3+ times more cpu time than Google Chrome. Maybe this is already the reason for the bad performance on YouTube and/or there are another significant performance issues.

Comment 1

[Jean-Yves Avenard [:jya]]

Please try again with Firefox Nightly (52).

Hardware accelerated compositing was enabled in Firefox Developer Edition. It will massively improve UI performance

Comment 2

[sworddragon2]

I have tested this on the current Nightly (downloaded version 52 and shortly after starting it it upgraded to version 53) with a new profile and the player controls do now indeed react immediately and the needed cpu time on the mouse movements went down from ~200% to ~35%-40% of 600%. On testing this on Firefox 49 again with another new profile the slow reaction on the player controls still exist but interestingly the needed cpu time for the mouse movements is low too. I could figure out that the high cpu time issue is caused if the setting javascript.options.strict is set to true even if no web console is opened.

I think this behavior is more or less expected because the messages for the web console are already registered even if the web console is not opened as past messages are shown if the web console gets opened later but maybe there is something that can be optimized to not affect the performance that much. Also it seems there is no way to disable this behavior if the web console is closed (if I'm not wrong for example Microsoft Edge does this at default). Maybe such an option could make sense here and maybe it should be enabled at default (as even with javascript.options.strict set to false there might be a potential performance impact depending how many warnings/errors a site throws).

Comment 3

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Any thoughts on javascript.options.strict ?

Comment 4

[sworddragon2]

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) [afk 24 Dec - 8 Jan] from comment #3)
> Any thoughts on javascript.options.strict ?

Have you in mind to eventually remove this option? If you check any random site from a major company like Google while having javascript.options.strict set to true you will extremely unlikely not see the web console being spammed with related warnings - so web developers seem not to make that much use of this option. But actually it is useful and can give often hints similar to enabled warnings of a compiler to issues that can point to bugs that have potential to cause severe errors (which are in my opinion not rare enough on mentioned sites) like accessing an undefined property.


Maybe the question is what this option is used for. For me it is to check my own sites for these compiler-like warnings to improve the quality - I'm normally not interested to see them in sites I browse and do not develop. It could be useful to change javascript.options.strict from a boolean to a string which is a regular expression of sites where this option gets enabled (for example the user could use then ^(file://|https?://localhost([#/?]|)) to enable this option only for sites on the file protocol and the local webserver). Alternatively this option could be changed to be site-driven instead of being a client-sided option. For example sites could opt-in strict warnings with a pragma (similar to 'use strict';) if they want to show these additional warnings.

Comment 5

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

I'm going to close this bug. Obviously javascript.options.strict was making things slow.