Closed Bug 1363335 (SearchFirstResult_YouTube) Opened 5 years ago Closed 4 years ago

YouTube search first result is slow

Categories

(Core :: General, defect)

55 Branch
x86_64
Windows 10
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr52 --- wontfix
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- fixed

People

(Reporter: arus, Unassigned)

References

(Blocks 2 open bugs, )

Details

(Keywords: meta, Whiteboard: [QRC])

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
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()
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: Quantum
Keywords: meta
Alias: QRC_YouTubeSearchFirstResult → YouTubeSearchFirstResult
Alias: YouTubeSearchFirstResult → SearchFirstResult_YouTube
Blocks: QRC_FX57
No longer blocks: Quantum
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)
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
Closed: 4 years ago
Flags: needinfo?(cpeterson)
Resolution: --- → FIXED
Sounds great, :) 
Thanks for your feedback here, Chris!
You need to log in before you can comment on or make changes to this bug.