1363335 - (SearchFirstResult_YouTube) YouTube search first result is slow

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Alin Rus]

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

[(no longer active)]

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

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

(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.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

FWIW, When I tried profiling on qf reference laptop, I got 4ms under nsContentUtils::ParseFragmentHTML()

Comment 4

[Alin Rus]

https://perfht.ml/2q0f16P
Here's the Gecko profile obtained on Acer Aspire e15.
Version: 55.0a1
Windows 10 64 bit
buildID: 20170518030213

Comment 5

[Chris Peterson [:cpeterson]]

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.

Comment 6

[Jonathan Watt [:jwatt]]

All the blocking bugs are fixed. How's this looking for you now, Alin?

Comment 7

[Alin Rus]

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!

Comment 8

[Chris Peterson [: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

Comment 9

[Alin Rus]

Sounds great, :) 
Thanks for your feedback here, Chris!