Bug 1363335 (SearchFirstResult_YouTube)

YouTube search first result is slow

RESOLVED FIXED

Status

()

RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: arus, Unassigned)

Tracking

(Blocks: 2 bugs, {meta})

55 Branch
x86_64
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 wontfix, firefox55 wontfix, firefox56 wontfix, firefox57 fixed)

Details

(Whiteboard: [QRC], URL)

(Reporter)

Description

2 years ago
Name: Firefox
Version: 55.0a1
Windows 10 64 bit
buildID: 20170508030204

Steps to reproduce:
1. Launch browser.
2. Fill youtoube.com in Navigation Start, then press enter.
3. Record with Gecko Profile:
   Type "mozilla" in youtube searchbox, then press enter.
4. Capture profile.
5. Share the profile.

Gecko profile:
https://perfht.ml/2pZI6Ci

Notes:
https://docs.google.com/spreadsheets/d/1Kxn850VasyaG_WfRg3pMInW0hbIT8LP7pRPBYTIpdbM/edit?pli=1#gid=1483467512

Comment 1

2 years ago
Here is a profile I captured: https://perfht.ml/2rgqfIg

Let's look at what happens here (note that due to the profiler 2ms resolution on Windows, the ms times here should all be multiplied by 2):

 * 30ms in gfxDWriteFont::MeasureGlyphWidth(), bug 1365776
 * 56ms in ElementBinding::set_innerHTML() under:
  ** 31ms under nsCSSFrameConstructor::ContentRemoved(), bug 1365783
  ** 14ms under nsContentUtils::ParseFragmentHTML().  Olli, since you have looked at this stuff lately, can you think of more things we can optimize here?  See this profile: https://perfht.ml/2rgkryk.  This looks like a death by a thousand cuts to me...
  ** Some extra additional waste...  I suspect that waste is already reduced due to some of the work that was done under bug 1347376.  It would be worth keeping an eye on this waste to see if it becomes more important when reprofiling after the other parts here get improved.
 * 11ms under json_parse(), bug 1365793
 * Investigate rasterization times, bug 1365794
Flags: needinfo?(bugs)
Summary: STR Youtube search first result → Quantum Release Criteria: Youtube search first result
(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from
>   ** 14ms under nsContentUtils::ParseFragmentHTML().  Olli, since you have
> looked at this stuff lately, can you think of more things we can optimize
> here?  See this profile: https://perfht.ml/2rgkryk.  This looks like a death
> by a thousand cuts to me...
Would probably need to get some more representative and reliable profile, some testcase which one could run easily several times.
Or profiling using a native profiler might reveal something more useful.
Or aren't we getting more accurate profiling on Windows too soon?

But nothing unusual is showing up there. Attribute setting tends to show up in other profiles too, since, well that just needs to do quite a bit work.
I guess the profile is so short or not accurate enough that malloc/free isn't really there too badly.
Flags: needinfo?(bugs)
FWIW, When I tried profiling on qf reference laptop, I got 4ms under nsContentUtils::ParseFragmentHTML()
(Reporter)

Comment 4

2 years ago
https://perfht.ml/2q0f16P
Here's the Gecko profile obtained on Acer Aspire e15.
Version: 55.0a1
Windows 10 64 bit
buildID: 20170518030213
Alias: QRC_YouTubeSearchFirstResult
Blocks: 1325169
Keywords: meta

Updated

2 years ago
Alias: QRC_YouTubeSearchFirstResult → YouTubeSearchFirstResult

Updated

2 years ago
Alias: YouTubeSearchFirstResult → SearchFirstResult_YouTube

Updated

2 years ago
Blocks: 1370336

Updated

2 years ago
No longer blocks: 1325169
Ehsan and Olli analyzed the few profiles above and we have some actionable blocking bugs, so there is no additional analysis needed at the moment.
Summary: Quantum Release Criteria: Youtube search first result → Youtube search first result is slow
Whiteboard: [QRC]
Assignee: nihsanullah → nobody
Summary: Youtube search first result is slow → YouTube search first result is slow
All the blocking bugs are fixed. How's this looking for you now, Alin?
Flags: needinfo?(arus)
(Reporter)

Comment 7

a year ago
For sure we have an increase of performance here as we look over Benchmark testing results, but still we don't meet our release criteria to be faster than Chrome, slightly difference remains between. 

Frames number for Youtube Search HeroElement on last 4 weekly builds: 
run_date____|_____Firefox_____|____Chrome_____|  
2017-09-05 _|_ _ _ _38.5_ _ _ |_ _ _36.00_ _ _|        
2017-08-28 _|_ _ _ _ 45 _ _ _ |_ _ _ 47 _ _ _ |
2017-08-21 _|_ _ _ _ 50 _ _ _ |_ _ _ 39.5 _ _ |
2017-08-14 _|_ _ _ _45.5_ _ _ |_ _ _ 33 _ _ _ |


More results can be found here: 
https://docs.google.com/a/mozilla.com/spreadsheets/d/1UMsy_sZkdgtElr2buwRtABuyA3GY6wNK_pfF01c890A/edit?usp=sharing

Kinds regards, 
Alin

p.s. sorry for late response on this, I was in PTO for 2 weeks 

     Chris, please take a look on this and let us know your input over this, thanks!
Flags: needinfo?(arus) → needinfo?(cpeterson)
Thanks, Alin. Our 57 release criterion for the page load tests is "no worse than 20% slower than Chrome" on first paint and hero element times. There is always more work that could be done, but I think we can resolve this bug as fixed because we are within 20% on these two measurements. :D
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox55: --- → wontfix
status-firefox56: --- → wontfix
status-firefox57: --- → fixed
status-firefox-esr52: --- → wontfix
Flags: needinfo?(cpeterson)
Resolution: --- → FIXED
(Reporter)

Comment 9

a year ago
Sounds great, :) 
Thanks for your feedback here, Chris!
You need to log in before you can comment on or make changes to this bug.