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
(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.
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 → YouTubeSearchFirstResult
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
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?
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
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.