1397092 - High Cpu/GPU usage due to "Ping Pong" loading indicators in Firefox 57 affecting browser performance

Status: RESOLVED DUPLICATE of bug 1406414

(Firefox :: Theme, defect)

Description

[u595893]

User Agent: Mozilla/5.0 (Windows NT 10.0; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170905220108

Steps to reproduce:

STR:

32 bit on windows 10 rs 2
Fresh profile with defaults

install Build from 2017-08-10
open 10 bookmarks at once and start typing in comment box here

notice the time taken to render the pages and switching between them, CPU use in task manager.

Install new build and repeat.

notice the time increase and cpu spike

ER:Pages are loaded fast with very low CPU use and no lags
AR: Pages load after taking a very long time with CPU fan churning & typing comments in the box is laggy

enabling/disabling servo has no visual improvements

Comment 1

[u595893]

Try to resize pages  and typing in the comment box before and after loading of the pages and in taskmanager see the cpu usage

Comment 2

[:Gijs (he/him)]

(In reply to shellye from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 10.0; rv:57.0) Gecko/20100101
> Firefox/57.0
> Build ID: 20170905220108
> 
> Steps to reproduce:
> 
> STR:
> 
> 32 bit on windows 10 rs 2

What is "rs 2"?

> Fresh profile with defaults
> 
> install Build from 2017-08-10
> open 10 bookmarks at once and start typing in comment box here

Which 10 bookmarks? How are you opening them "at once"?

> notice the time taken to render the pages and switching between them, CPU
> use in task manager.
>
> Install new build and repeat.

still 32 bit or not?

> notice the time increase and cpu spike

Can you provide a performance profile ( https://perf-html.io/ ) before/after overview? Or find a narrower regression window?

Comment 3

[u595893]

(In reply to :Gijs from comment #2)
> (In reply to shellye from comment #0)
> > User Agent: Mozilla/5.0 (Windows NT 10.0; rv:57.0) Gecko/20100101
> > Firefox/57.0
> > Build ID: 20170905220108
> > 
> > Steps to reproduce:
> > 
> > STR:
> > 
> > 32 bit on windows 10 rs 2
> 
> What is "rs 2"?
> 
REDSTONE 2(creators update?)
Tested on RS3(fall's update?)

> > Fresh profile with defaults
> > 
> > install Build from 2017-08-10
> > open 10 bookmarks at once and start typing in comment box here
> 
> Which 10 bookmarks? How are you opening them "at once"?

Just bookmark random pages and open then at once or click on them one by one.
will try to add the bookmark links

> 
> > notice the time taken to render the pages and switching between them, CPU
> > use in task manager.
> >
> > Install new build and repeat.
> 
> still 32 bit or not?
> 

only on 32 bit(have a 32bit OS)

> > notice the time increase and cpu spike
> 
> Can you provide a performance profile ( https://perf-html.io/ ) before/after
> overview? Or find a narrower regression window?

OK trying to post but have no idea about it?
What steps should be done?

Run the profiler and reproduce the issue?
and share the link?

Comment 4

[:Gijs (he/him)]

(In reply to shellye from comment #3)
> (In reply to :Gijs from comment #2)
> > Can you provide a performance profile ( https://perf-html.io/ ) before/after
> > overview? Or find a narrower regression window?
> 
> OK trying to post but have no idea about it?
> What steps should be done?
> 
> Run the profiler and reproduce the issue?
> and share the link?

Yes, once for the old and once for the new build.

Comment 5

[u595893]

New to this so,
typing this in today's FF57 build
and attaching the profile url
typing is laggy here and in reddit /r/aww login too and pages are still loading and will wait till they complete ie throbber stops.

https://perfht.ml/2gHkDiS

Doing in the other with same preference

Comment 6

[u595893]

Doing the exact same thing as comment 5,
no lag while typing or login and will wait till the page loads.

Switched to each tab after loading in both cases and had the same pages.

https://perfht.ml/2gH05Hi

Comment 7

[:Gijs (he/him)]

I don't see anything obvious in the profile, though there seems to be a lot more web activity in the "new" profile, there are also no symbols for xul.dll, which makes it difficult to say much.

A regression window, and a profile that does have symbols, would be helpful. In the meantime I'll tag this as qf and maybe the quantum folks can figure more stuff out here.

Comment 8

[u595893]

(In reply to :Gijs from comment #7)
> I don't see anything obvious in the profile, though there seems to be a lot
> more web activity in the "new" profile, there are also no symbols for
> xul.dll, which makes it difficult to say much.
> 
> A regression window, and a profile that does have symbols, would be helpful.
> In the meantime I'll tag this as qf and maybe the quantum folks can figure
> more stuff out here.

how to add symbols for xul.dll ?
what do you mean by "new profile activity"? It's default with only restore previous session.
will try to do with it tomorrow? 
can  you help ?
have no issues with older version just FF57 recently.

Comment 9

[u595893]

Are there any test where we can compare the performance of say FF56 & FF57 to see if it regressed?
If so can you try that?

Comment 10

[:Gijs (he/him)]

(In reply to shellye from comment #8)
> (In reply to :Gijs from comment #7)
> > I don't see anything obvious in the profile, though there seems to be a lot
> > more web activity in the "new" profile, there are also no symbols for
> > xul.dll, which makes it difficult to say much.
> > 
> > A regression window, and a profile that does have symbols, would be helpful.
> > In the meantime I'll tag this as qf and maybe the quantum folks can figure
> > more stuff out here.
> 
> how to add symbols for xul.dll ?

I don't know - maybe wait longer before sharing the profile after updating it, until all the "waiting for symbols for XUL.dll to load" notifications at the top have finished?

> what do you mean by "new profile activity"? It's default with only restore
> previous session.

... in addition to the bookmarks, there's other pages that are loaded? That will make a big difference.

The profile from the "slow"/"new" build shows JS running from yahoo and google+ scripts that isn't present (or at least, not as high-profile) as in the other build. That doesn't make a lot of sense. Are the testcases you're running on these builds actually the same? It doesn't look like it...

(In reply to shellye from comment #9)
> Are there any test where we can compare the performance of say FF56 & FF57
> to see if it regressed?

There are a lot of those types of tests and they show improvements, not regressions. It's still possible that something specific is slower now, but it's only really possible to fix something like that once you identify what the specific thing is that's slower. Just saying "10 bookmarks, doesn't matter what they are" is not specific, so unless you identify a specific regression window or a profile with a "smoking gun" style difference, it's unlikely this bug will be actionable.

Comment 11

[u595893]

(In reply to :Gijs from comment #10)
> (In reply to shellye from comment #8)
> > (In reply to :Gijs from comment #7)
> > > I don't see anything obvious in the profile, though there seems to be a lot
> > > more web activity in the "new" profile, there are also no symbols for
> > > xul.dll, which makes it difficult to say much.
> > > 
> > > A regression window, and a profile that does have symbols, would be helpful.
> > > In the meantime I'll tag this as qf and maybe the quantum folks can figure
> > > more stuff out here.
> > 
> > how to add symbols for xul.dll ?
> 
> I don't know - maybe wait longer before sharing the profile after updating
> it, until all the "waiting for symbols for XUL.dll to load" notifications at
> the top have finished?
>

ok will try again tomorrow.
 
> > what do you mean by "new profile activity"? It's default with only restore
> > previous session.
> 
> ... in addition to the bookmarks, there's other pages that are loaded? That
> will make a big difference.

no loading from bookmarks after startup.
from firefox homepage

> 
> The profile from the "slow"/"new" build shows JS running from yahoo and
> google+ scripts that isn't present (or at least, not as high-profile) as in
> the other build. That doesn't make a lot of sense. Are the testcases you're
> running on these builds actually the same? It doesn't look like it...
> 

ok will create the bookmarks and share then you can try..
both cases same bookmarks/pages, will try to bookmark pages which show the difference most..
So maybe that's the issue?

> (In reply to shellye from comment #9)
> > Are there any test where we can compare the performance of say FF56 & FF57
> > to see if it regressed?
> 
> There are a lot of those types of tests and they show improvements, not
> regressions. It's still possible that something specific is slower now, but
> it's only really possible to fix something like that once you identify what
> the specific thing is that's slower. Just saying "10 bookmarks, doesn't
> matter what they are" is not specific, so unless you identify a specific
> regression window or a profile with a "smoking gun" style difference, it's
> unlikely this bug will be actionable.

new to this so don't know the basics yet but trying to help so please ,
typing while pages load is slower that's for sure and pages load a lot slower so from 10 sec to 60 sec now.
will try with symbols maybe that will help but definitely something is wrong because until recently could see the improvements and now suddenly it's gone, it's like reverting to FF  45,
if you could tell me what to do it would be easier.
but will try tomorrow with more details.
one more thing could this be win32+FF32bit issue?


in profiler can i stop it while it's collecting & uploading since its says stop & discard even after capture profile?

Comment 12

[u595893]

https://perfht.ml/2j3m4fO

Waiting for symbol tables for library xul.pdb...

getting stuck here so no symbols.
So any advice?

Comment 13

[u595893]

Attachment: The bookmarks(load test folder all at once)

Comment 14

[u595893]

Finally got it to work, typing in this bug is lagged as well as in the login box of /r/aww
pages are still loading on, waiting and attaching the profile after they finish loading and switch to them,
hope this will help.

https://perfht.ml/2j4HoBU

Did not work with this but had severe slowdowns

https://perfht.ml/2j4nJBU

https://perfht.ml/2eIg1Z5

Now comparing with FF 55(same profile)

https://perfht.ml/2eHEkXr

please note the total duration in this with FF57
There is a severe difference in loading time in FF57(profiler was running till the page loads completely and slowdown stopped)

Comment 15

[u595893]

For some reason cannot link with symbols, will try when new nightly comes out today.
Here is the profiler


https://perfht.ml/2vOgdBd

Comment 16

[:Gijs (he/him)]

Without symbols, these profiles are not a lot of use, tbh. I tried to reproduce but I don't see any real difference. If anything, looking at the profiler, on 56 beta there are longer content process delays than on 57.

(In reply to shellye from comment #12)
> https://perfht.ml/2j3m4fO
> 
> Waiting for symbol tables for library xul.pdb...
> 
> getting stuck here so no symbols.
> So any advice?

Loading symbols can take a long time, especially for profiles as long as the ones you're attaching. Consider waiting longer?

Comment 17

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

How about getting regression range with mozregression GUI[1]?
Documentation with QuickStart info is here[2]



[1] = https://github.com/mozilla/mozregression/releases
[2] = https://mozilla.github.io/mozregression/quickstart.html

Comment 18

[u595893]

(In reply to :Gijs from comment #16)
> Without symbols, these profiles are not a lot of use, tbh. I tried to
> reproduce but I don't see any real difference. If anything, looking at the
> profiler, on 56 beta there are longer content process delays than on 57.
> 
> (In reply to shellye from comment #12)
> > https://perfht.ml/2j3m4fO
> > 
> > Waiting for symbol tables for library xul.pdb...
> > 
> > getting stuck here so no symbols.
> > So any advice?
> 
> Loading symbols can take a long time, especially for profiles as long as the
> ones you're attaching. Consider waiting longer?

In FF55 it took a minute, but in FF57 it's just waiting, no cpu use etc, how long should it take?(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #17)
> How about getting regression range with mozregression GUI[1]?
> Documentation with QuickStart info is here[2]
> 
> 
> 
> [1] = https://github.com/mozilla/mozregression/releases
> [2] = https://mozilla.github.io/mozregression/quickstart.html

Thanks but not sure since when this is happening and downloading full builds on slow connection will be painful.
But will try, can you guys say if any major thing landed in last couple of weeks which affects input & cpu use?
might try from there.

Comment 19

[u595893]

So trying but can confirm this much that FF57 08082017 build does not have this issue.

Comment 20

[u595893]

Now getting the windows wait cursor for a few seconds on page load. Just started on the August 11082017 build. Happens without any extensions and plugins.

Comment 21

[Alice0775 White]

(In reply to shellye from comment #20)
> Now getting the windows wait cursor for a few seconds on page load. Just
> started on the August 11082017 build. Happens without any extensions and
> plugins.

It seems to be Bug 1395187.

Comment 22

[u595893]

Found it,

working fine

FF57 20 Aug 2017

Starting of major slow downs starts from

21/22 Aug 2017 

just after dogfox logo build

now how to know what caused it?

Comment 23

[Alice0775 White]

(In reply to shellye from comment #22)
> Found it,
> 
> working fine
> 
> FF57 20 Aug 2017
> 
> Starting of major slow downs starts from
> 
> 21/22 Aug 2017 
> 
> just after dogfox logo build
> 
> now how to know what caused it?



Using mozregression (see comment #17)


shellye,
BTW, Could you attach the results of about:support?
And Some additional information if you do not mind
1. Network Connection Speed
2. Number of CPU core
3. Memory free space

Comment 24

[u595893]

Attachment: ff57 loading time

Comment 25

[u595893]

Attachment: FF56b see the speed difference in loading time(plus fans don't start running even)

Comment 26

[u595893]

(In reply to Alice0775 White from comment #23)

> Using mozregression (see comment #17)

Tried using that bug how to get the regression ?

 
> shellye,
> BTW, Could you attach the results of about:support?
> And Some additional information if you do not mind
> 1. Network Connection Speed
> 2. Number of CPU core
> 3. Memory free space


What do you want from it?
Graphics section?

Sure
1.Vodafone LTE
2.Dual core
3.approx 2gb+ free with firefox & total ram 4gb.

Comment 27

[u595893]

Application Basics
------------------

Name: Firefox
Version: 57.0a1
Build ID: 20170907100318
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 10.0; rv:57.0) Gecko/20100101 Firefox/57.0
OS: Windows_NT 10.0
Multiprocess Windows: 1/1 (Enabled by default)
Web Content Processes: 3/4
Stylo: true (enabled by default)
Google Key: Found
Mozilla Location Service Key: Found
Safe Mode: false

Crash Reports for the Last 3 Days
---------------------------------

All Crash Reports

Nightly Features
----------------

Name: Activity Stream
Version: 2017.09.01.1439-222d033f
ID: [e-mail]

Name: Application Update Service Helper
Version: 2.0
ID: [e-mail]

Name: Click-to-Play staged rollout
Version: 1.2
ID: [e-mail]

Name: Firefox Screenshots
Version: 16.1.0
ID: [e-mail]

Name: FlyWeb
Version: 1.0.0
ID: [e-mail]

Name: Follow-on Search Telemetry
Version: 0.9.3
ID: [e-mail]

Name: Form Autofill
Version: 1.0
ID: [e-mail]

Name: Multi-process staged rollout
Version: 3.00
ID: [e-mail]

Name: Photon onboarding
Version: 0.1
ID: [e-mail]

Name: Pocket
Version: 1.0.5
ID: [e-mail]

Name: Presentation
Version: 1.0.0
ID: [e-mail]

Name: Shield Recipe Client
Version: 65
ID: [e-mail]

Name: Web Compat
Version: 1.1
ID: [e-mail]

Name: WebCompat Reporter
Version: 1.0.0
ID: [e-mail]

Extensions
----------

Graphics
--------

Features
Compositing: Direct3D 11 (Advanced Layers)
Asynchronous Pan/Zoom: wheel input enabled; scrollbar drag enabled; keyboard enabled; autoscroll enabled
WebGL 1 Driver WSI Info: EGL_VENDOR: Google Inc. (adapter LUID: 000000000000dc03) EGL_VERSION: 1.4 (ANGLE 2.1.0.dec065540d5f) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture_nv12 EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses
WebGL 1 Driver Renderer: Google Inc. -- ANGLE (AMD Radeon HD 7420G Direct3D11 vs_5_0 ps_5_0)
WebGL 1 Driver Version: OpenGL ES 2.0 (ANGLE 2.1.0.dec065540d5f)
WebGL 1 Driver Extensions: GL_ANGLE_depth_texture GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_request_extension GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object
WebGL 1 Extensions: ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_frag_depth EXT_shader_texture_lod EXT_texture_filter_anisotropic EXT_disjoint_timer_query MOZ_debug OES_element_index_uint OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object WEBGL_color_buffer_float WEBGL_compressed_texture_s3tc WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc MOZ_WEBGL_depth_texture
WebGL 2 Driver WSI Info: EGL_VENDOR: Google Inc. (adapter LUID: 000000000000dc03) EGL_VERSION: 1.4 (ANGLE 2.1.0.dec065540d5f) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture_nv12 EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses
WebGL 2 Driver Renderer: Google Inc. -- ANGLE (AMD Radeon HD 7420G Direct3D11 vs_5_0 ps_5_0)
WebGL 2 Driver Version: OpenGL ES 3.0 (ANGLE 2.1.0.dec065540d5f)
WebGL 2 Driver Extensions: GL_ANGLE_depth_texture GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_request_extension GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_norm16 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object
WebGL 2 Extensions: EXT_color_buffer_float EXT_texture_filter_anisotropic EXT_disjoint_timer_query MOZ_debug OES_texture_float_linear WEBGL_compressed_texture_s3tc WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc
Direct2D: true
DirectWrite: true (10.0.16251.0)
GPU #1
Active: Yes
Description: AMD Radeon HD 7420G
Driver Version: 15.200.1062.1002
Driver Date: 3-01-2016
Drivers: aticfx32 aticfx32 aticfx32 atiumdag atidxx32 atiumdva
Subsys ID: 3564103c
RAM: 1024

Diagnostics
AzureCanvasAccelerated: 0
AzureCanvasBackend: Direct2D 1.1
AzureCanvasBackend (UI Process): skia
AzureContentBackend: Direct2D 1.1
AzureContentBackend (UI Process): skia
AzureFallbackCanvasBackend (UI Process): cairo
GPUProcessPid: 6072
GPUProcess: Terminate GPU Process
Device Reset: Trigger Device Reset
Decision Log
WEBRENDER:
opt-in by default: WebRender is an opt-in feature




Media
-----

Audio Backend: wasapi
Max Channels: 2
Preferred Channel Layout: stereo
Preferred Sample Rate: 48000
Output Devices
Name: Group
Speakers (High Definition Audio Device): HDAUDIO\FUNC_01&VEN_111D&DEV_7605&SUBSYS_103C3564&REV_1001\4&101cf511&0&0001
Internal AUX Jack (High Definition Audio Device): HDAUDIO\FUNC_01&VEN_111D&DEV_7605&SUBSYS_103C3564&REV_1001\4&101cf511&0&0001
AMD HDMI Output (AMD High Definition Audio Device): HDAUDIO\FUNC_01&VEN_1002&DEV_AA01&SUBSYS_00AA0100&REV_1002\4&c5953c7&0&0001
Input Devices
Name: Group
Microphone (High Definition Audio Device): HDAUDIO\FUNC_01&VEN_111D&DEV_7605&SUBSYS_103C3564&REV_1001\4&101cf511&0&0001
Microphone (High Definition Audio Device): HDAUDIO\FUNC_01&VEN_111D&DEV_7605&SUBSYS_103C3564&REV_1001\4&101cf511&0&0001
AMD HDMI Output (AMD High Definition Audio Device): HDAUDIO\FUNC_01&VEN_1002&DEV_AA01&SUBSYS_00AA0100&REV_1002\4&c5953c7&0&0001

Important Modified Preferences
------------------------------

browser.cache.disk.capacity: 0
browser.cache.disk.filesystem_reported: 1
browser.cache.disk.smart_size.enabled: false
browser.cache.disk.smart_size.first_run: false
browser.cache.frecency_experiment: 4
browser.download.useDownloadDir: false
browser.places.importBookmarksHTML: false
browser.places.smartBookmarksVersion: 8
browser.sessionstore.upgradeBackup.latestBuildID: 20170907100318
browser.startup.homepage_override.buildID: 20170907100318
browser.startup.homepage_override.mstone: 57.0a1
browser.urlbar.lastSuggestionsPromptDate: 20170907
browser.urlbar.timesBeforeHidingSuggestionsHint: 0
dom.forms.autocomplete.formautofill: true
extensions.lastAppVersion: 57.0a1
layers.mlgpu.sanity-test-failed: false
media.gmp-gmpopenh264.abi: x86-msvc-x86
media.gmp-gmpopenh264.lastUpdate: 1504794579
media.gmp-gmpopenh264.version: 1.6
media.gmp-manager.buildID: 20170907100318
media.gmp-manager.lastCheck: 1504800662
media.gmp-widevinecdm.abi: x86-msvc-x86
media.gmp-widevinecdm.lastUpdate: 1504794588
media.gmp-widevinecdm.version: 1.4.8.1008
media.gmp.storage.version.observed: 1
media.hardware-video-decoding.failed: false
network.cookie.prefsMigrated: true
network.predictor.cleaned-up: true
places.history.expiration.transient_current_max_pages: 104858
plugin.disable_full_page_plugin_for_types: application/pdf
security.sandbox.content.tempDirSuffix: {b1ef002c-5f77-4753-b341-3e3a02789513}
services.sync.engine.addresses.available: true
ui.osk.debug.keyboardDisplayReason: IKPOS: Touch screen not found.

Important Locked Preferences
----------------------------

Places Database
---------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0
Accessible Handler Used: false
Accessibility Instantiator:

Library Versions
----------------

NSPR
Expected minimum version: 4.17 Beta
Version in use: 4.17 Beta

NSS
Expected minimum version: 3.33 Beta
Version in use: 3.33 Beta

NSSSMIME
Expected minimum version: 3.33 Beta
Version in use: 3.33 Beta

NSSSSL
Expected minimum version: 3.33 Beta
Version in use: 3.33 Beta

NSSUTIL
Expected minimum version: 3.33 Beta
Version in use: 3.33 Beta

Experimental Features
---------------------

Sandbox
-------

Content Process Sandbox Level: 4
Effective Content Process Sandbox Level: 4

Comment 28

[:Gijs (he/him)]

(In reply to shellye from comment #22)
> Found it,
> 
> working fine
> 
> FF57 20 Aug 2017
> 
> Starting of major slow downs starts from
> 
> 21/22 Aug 2017 
> 
> just after dogfox logo build
> 
> now how to know what caused it?

You use mozregression, you select 'good' 20th of august, 'bad' 23rd, and you narrow it down from there. In the end it should give you a URL to hg.mozilla.org's pushlog that identifies what set of changes made the behaviour so much worse for you.

Comment 29

[u595893]

(In reply to :Gijs from comment #28)
> (In reply to shellye from comment #22)
> > Found it,
> > 
> > working fine
> > 
> > FF57 20 Aug 2017
> > 
> > Starting of major slow downs starts from
> > 
> > 21/22 Aug 2017 
> > 
> > just after dogfox logo build
> > 
> > now how to know what caused it?
> 
> You use mozregression, you select 'good' 20th of august, 'bad' 23rd, and you
> narrow it down from there. In the end it should give you a URL to
> hg.mozilla.org's pushlog that identifies what set of changes made the
> behaviour so much worse for you.

Ok thank you .
Doing it and think found it, just one thing
if its going even worse after 23rd(since 23rd it started and gradually getting worse)
then what to do?
report 'good' 20th of august & 'bad' 23rd or continue further?

Comment 30

[u595893]

Attachment: The Culprit

Bug 1352119 - Implement new page loading indicator animation, part 1: update the throbber. Additional performance improvements implemented by Jared Wein. r=dao

Comment 31

[u595893]

Already had toolkit.cosmeticAnimations.enabled=false but still

Implement new page loading indicator animation, part 2: add a "burst" when loading finishes

part 2 is disabled but not part one,

Saw that problem mentioned in this bug seems to be similar in
bug 759252 & 1357093

Just to check asked someone to check if win64 had the issue,
It's turns out that in the new taskmanager (fall's creator update)
the CPU usage goes down `5% but GPU usage goes way high `with this new loading indicator!!
fan starts churning of Both CPU/GPU(i5 with nvidia GT 1030) when loading single page or multiple pages...

Disabled H/W again but still same...

So basically the CPU/GPU power is going into fancy stuff instead of the content and tabs which matters the most
and so all other stuff is slowing down...

Comment 32

[Mike Conley (:mconley) (:⚙️)]

I'll note that the about:support posted in comment 27 shows that shellye is working with 1024MB (1GB) of RAM[1].

If anybody is trying to reproduce this in the lab, they might want to try a machine with that much RAM.

[1]: Not to take away from this valid user report, I'll point out that the hardware report at https://hardware.metrics.mozilla.com/ shows that users with 1GB of RAM accounts for less than 2% of our user base, but this number is slowly creeping up.

Comment 33

[Mike Conley (:mconley) (:⚙️)]

Hey shellye, I have an experiment for you to try:

Does it help if you go to about:config and set dom.ipc.processCount to 2 ? (you might need to restart after setting that pref)

Comment 34

[Jared Wein [:jaws] (please needinfo? me)]

Eric, can you create an animated PNG of the new loading indicator? Shorlander may be able to help you. We could use this APNG for users with lower hardware specs. This is pretty high priority since we don't want the Photon release to be perceived as slower.

Comment 35

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #33)
> Hey shellye, I have an experiment for you to try:
> 
> Does it help if you go to about:config and set dom.ipc.processCount to 2 ?
> (you might need to restart after setting that pref)

[1]: it's 1 GB DDR3 (Dedicated) GPU ram, system ram is 4GB & CPU is AMD A4-4300M
but many systems have less than 512MB GPU ram(eg:shared with system ram -> 1.5GB system and 512mb GPU out of 2GB)
So systems with 1GB or 2GB of ram will have horrible experience with this new loading indicator. 

Tried with 2 & 1 but same result...

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #34)
> Eric, can you create an animated PNG of the new loading indicator?
> Shorlander may be able to help you. We could use this APNG for users with
> lower hardware specs. This is pretty high priority since we don't want the
> Photon release to be perceived as slower.

can we please have an option to disable it **completely** ? Like the "Burst"
or at least let the user *choose* between slower loading indicator vs this high speed one?
because this system is not lower hardware specs - 2.5 GHz With Turbo Core Technology Upto 3.0 GHz
but still struggles so would like an option to manually override this.. 
Also high priority means this should be P1 not P3? right?.

Comment 36

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to shellye from comment #35)
> can we please have an option to disable it **completely** ? 

Not really. We don't want to provide an option to completely disable the loading indicator because it's a pretty fundamental part of the web browser and we don't want users to change a pref, stop using Firefox for a couple months, come back to Firefox and have it feeling broken and not remember why it's "broken" and thus completely give up on Firefox. In short, we don't want to make it possible to screw up Firefox.

> Like the "Burst"
> or at least let the user *choose* between slower loading indicator vs this
> high speed one?

If we implement the APNG version it will use the same implementation as the previous loading indicator, which means that the animation may skip frames and stutter. Ideally I would like to implement it where we would automatically use the APNG version if the machine is below some determined hardware spec. At that point it would be simple to allow users to manually opt-in to this through about:config, as well this pref would probably be necessary for QA anyways.

> because this system is not lower hardware specs - 2.5 GHz With Turbo Core
> Technology Upto 3.0 GHz
> but still struggles so would like an option to manually override this.. 

Sorry, I didn't mean to diss your machine. I only used "lower hardware specs" based on mconley's cited statistics.

> Also high priority means this should be P1 not P3? right?.

The values for these may be confusing at the moment. Bugs marked as P3 are tracked as to get fixed in Firefox 57. When a bug is actively being worked on it will be changed to P1. Until I have an asset (and mutual agreement that my idea is acceptable) from UX I won't start working on this bug.

Comment 37

[Mike Conley (:mconley) (:⚙️)]

Yeah, I apologize - I misread the about:support, and thought it was saying 1GB of system RAM. I've obsoleted my comment.

Comment 38

[u595893]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #36)
> (In reply to shellye from comment #35)
> > can we please have an option to disable it **completely** ? 
> 
> Not really. We don't want to provide an option to completely disable the
> loading indicator because it's a pretty fundamental part of the web browser
> and we don't want users to change a pref, stop using Firefox for a couple
> months, come back to Firefox and have it feeling broken and not remember why
> it's "broken" and thus completely give up on Firefox. In short, we don't
> want to make it possible to screw up Firefox.

OK that makes sense

> > Like the "Burst"
> > or at least let the user *choose* between slower loading indicator vs this
> > high speed one?
> 
> If we implement the APNG version it will use the same implementation as the
> previous loading indicator, which means that the animation may skip frames
> and stutter. Ideally I would like to implement it where we would
> automatically use the APNG version if the machine is below some determined
> hardware spec. 

users won't mind the stutter or skipping of frames or being slow like 10fps if it uses least amount of *Resource* for fancy stuff as they get used to the animation very quickly and it's ignored mostly
but it should not slow down the main priority which is the "content" & "Rendering Speed"
Which is *where* the user's notice it the most.

>At that point it would be simple to allow users to manually
> opt-in to this through about:config, as well this pref would probably be
> necessary for QA anyways.

Thank you it will be very much appreciated surely.
 
> >because this system is not lower hardware specs - 2.5 GHz With Turbo Core
> > Technology Upto 3.0 GHz
> > but still struggles so would like an option to manually override this.. 
> 
> Sorry, I didn't mean to diss your machine. I only used "lower hardware
> specs" based on mconley's cited statistics.

Don't need to apologize just meant that if this Machine is having such huge *issues*
just think of user with lower specs and their reaction will be perceived as "It's slower than Chrome/Vivaldi"
(like linux boxes at our school which are *Donated by people for students to use*
and have x64 linux with 1GB or 2GB of ram max.

*Most* won't bother to do the stuff which has been done earlier in this bug to find the issue and get it fixed,
they will just switch and bad mouth the UX of Firefox so you guys need to be sure of 
*Not Slowing-down the Rendering or Switching in search of Improvements in perceived performance*

> > Also high priority means this should be P1 not P3? right?.
> 
> The values for these may be confusing at the moment. Bugs marked as P3 are
> tracked as to get fixed in Firefox 57. When a bug is actively being worked
> on it will be changed to P1. Until I have an asset (and mutual agreement
> that my idea is acceptable) from UX I won't start working on this bug.

Thank you for all the explanations, hope you guys can fix this fast as beta merge date has been changed and is a week or so?

(In reply to Mike Conley (:mconley) (:⚙️) from comment #37)
> Yeah, I apologize - I misread the about:support, and thought it was saying
> 1GB of system RAM. I've obsoleted my comment.

No please don't happy to hear you think of the users so much and try to make it work better even on extremely *Low Specs*
just wanted to highlight it & bring it to your notice so you guys know & the reasons why as explained above.

Comment 39

[u595893]

(In reply to :Gijs from comment #28)
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #17)
(In reply to Alice0775 White from comment #21)

Thank you for helping out, Would have not found this BUG & it would have crept under if you guys didn't guide.

Comment 40

[Eric Pang [:epang] UX]

Yes, I'll look into a APNG for this.

Comment 41

[Jared Wein [:jaws] (please needinfo? me)]

Mike, do you know what metric we can use to automatically fallback to the APNG implementation? Also bonus points if you know how to read those metrics from Firefox :)

Comment 42

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1397092 - Switch to an APNG loading indicator when the browser is under schedule pressure.

Review commit: https://reviewboard.mozilla.org/r/177508/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/177508/

Comment 43

[u595893]

Tested on two of the Linux pc's so see if they very affected on *Low powered devices* win x86 & x64
since initially had on done it on win32 bit OS+FF32bits,
seems they *are* affected too but were/is not noticed because using AMD/Nvidia/intel drivers,
the Linux task-manager does not account for GPU usage so it's not reflected, so it seems that CPU usage is reduced but CPU/GPU usage is very high,
page loading time is higher similar to what is on win32.
One had 1GB(legacy os x32) of ram another had 1.5GB(bodhix64) of Ram, single core and dual core with FF57 nightly

Manually enabled/disable H/W acceleration but no improvements but got artifacts in some pages.

Videos can play FullHD videos but loading pages just makes it churn the fans & the PC's throttles making it worse
Rendering of pages is painfully slow even with servo and page loading time has increased just like win32.
Could this be really affecting all builds and not 32bits on windows?

Dreading this as all the user visible improvements you guys made since release of Firefox 53
seems to be *Negated* by this *ONE* bug.

Sorry was in a rush so did not note the support section.

Just for info:
OpenCL was being used & on win32 it was direct3d11?
+
Webgl in both.

Will web-render surpass these in terms of performance & efficiency?

Comment 44

[Eric Pang [:epang] UX]

Attachment: APNGS.zip

Jared, here's the animated pngs.

Comment 45

[u595893]

(In reply to Eric Pang [:epang] UX from comment #44)
> Created attachment 8905752 [details]
> APNGS.zip
> 
> Jared, here's the animated pngs.

Do the New Loading indicators use the same resources on all platforms?

Will Firefox get a "tab progress meter" like TabMixPlus offers & Vivaldi natively in future builds like FF59?
It feels much more better in terms of perceived performance with those loaders on each tab without slowing down anything(TMP one).

Comment 46

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8905710 [details]
Bug 1397092 - Switch to an APNG loading indicator when the browser is under schedule pressure.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/177508/diff/1-2/

Comment 47

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #41)
> Mike, do you know what metric we can use to automatically fallback to the
> APNG implementation? Also bonus points if you know how to read those metrics
> from Firefox :)

Clearing the needinfo request now that I've switched to relying on the toolkit.cosmeticAnimations.enabled pref. We have bug 1351413 on file to implement a smart way to determine when animations should be disabled.

(In reply to shellye from comment #45)
> Do the New Loading indicators use the same resources on all platforms?

Yes, but the various platforms have different graphics backend implementations.
 
> Will Firefox get a "tab progress meter" like TabMixPlus offers & Vivaldi
> natively in future builds like FF59?

Not that I know of.

> Will web-render surpass these in terms of performance & efficiency?

I don't know the answer to this question. WebRender and this loading indicator animation are quite disjoint, with WebRender mainly affecting web content which runs in a separate process than the browser UI.

Comment 48

[u595893]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #47)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #41)
> > Mike, do you know what metric we can use to automatically fallback to the
> > APNG implementation? Also bonus points if you know how to read those metrics
> > from Firefox :)
> 
> Clearing the needinfo request now that I've switched to relying on the
> toolkit.cosmeticAnimations.enabled pref. We have bug 1351413 on file to
> implement a smart way to determine when animations should be disabled.
> 
> (In reply to shellye from comment #45)
> > Do the New Loading indicators use the same resources on all platforms?
> 
> Yes, but the various platforms have different graphics backend
> implementations.
>  
> > Will Firefox get a "tab progress meter" like TabMixPlus offers & Vivaldi
> > natively in future builds like FF59?
> 
> Not that I know of.
> 
> > Will web-render surpass these in terms of performance & efficiency?
> 
> I don't know the answer to this question. WebRender and this loading
> indicator animation are quite disjoint, with WebRender mainly affecting web
> content which runs in a separate process than the browser UI.

Thanks and concerns regarding Comment 43?

Comment 49

[Jared Wein [:jaws] (please needinfo? me)]

There are simply too many moving pieces to attach all of the issues described in comment #43 to this one bug. If you know how, you can apply the patch that I attached to this bug and see if it fixed the issue for you. Otherwise I can post a link to a build tomorrow that you can download and test.

Comment 50

[u595893]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #49)
> There are simply too many moving pieces to attach all of the issues
> described in comment #43 to this one bug. If you know how, you can apply the
> patch that I attached to this bug and see if it fixed the issue for you.
> Otherwise I can post a link to a build tomorrow that you can download and
> test.

That would be great, so can test on linux x86/64 and see how it goes.

Comment 51

[Dão Gottwald [:dao]]

Comment on attachment 8905710 [details]
Bug 1397092 - Switch to an APNG loading indicator when the browser is under schedule pressure.

https://reviewboard.mozilla.org/r/177508/#review182726

It's very quiet over in bug 1351413. Without confidency that we can reliably detect systems / situations where the CSS-animated throbber is problematic, this doesn't seem like a sufficient solution.

Comment 52

[Mike Conley (:mconley) (:⚙️)]

I think I may have accidentally misled folks in comment 32 by making it seem that this was an underpowered machine. Here are the stats gathered from various comments from shellye from this bug:

OS: 32-bit Windows 10 with Creators Update
CPU: 2.5 GHz With Turbo Core Technology Upto 3.0 GHz
RAM: 4GB
Video card: AMD Radeon HD 7420G, 2GB of video memory

So I don't think we should be focusing on addressing this for low powered machines or anything - that doesn't seem to be the problem here.

One thing that's worth pointing out is that in comment 26, shellye mentions that they're on a "Vodafone LTE" network. Has anybody done the STR with LTE-like network conditions? Have we tried it with 32-bit OS's and builds of Firefox?

Comment 53

[Mike Conley (:mconley) (:⚙️)]

I also feel like we should be trying to get profiles from shellye here - but the ones that have been provided are all unsymbolicated, which isn't helpful.

I wonder if that's the LTE Network hitting us here - downloading those symbols might just be taking a super long time.

shellye, do you have the ability to test the performance on a different network to see if that changes the behaviour?

Comment 54

[Mike Conley (:mconley) (:⚙️)]

Also, shellye, if you have the time, could you please provide a similar video as the ones for FF57 and FF56b for this build:

https://ftp.mozilla.org/pub/firefox/nightly/2017/08/2017-08-20-10-03-43-mozilla-central/firefox-57.0a1.en-US.win32.zip

Comment 55

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #52)
> I think I may have accidentally misled folks in comment 32 by making it seem
> that this was an underpowered machine. Here are the stats gathered from
> various comments from shellye from this bug:
> 
> OS: 32-bit Windows 10 with Creators Update
> CPU: 2.5 GHz With Turbo Core Technology Upto 3.0 GHz
> RAM: 4GB
> Video card: AMD Radeon HD 7420G, 2GB of video memory
> 
> So I don't think we should be focusing on addressing this for low powered
> machines or anything - that doesn't seem to be the problem here.
> 
> One thing that's worth pointing out is that in comment 26, shellye mentions
> that they're on a "Vodafone LTE" network. Has anybody done the STR with
> LTE-like network conditions? Have we tried it with 32-bit OS's and builds of
> Firefox?

No it's definitely the problem as was using Vodafone-lte for regression range,
But the issue happens at the school too with high speed connection (and the machines are under powered)
and builds since the "New loading indicator" have the issues

(In reply to Mike Conley (:mconley) (:⚙️) from comment #53)
> I also feel like we should be trying to get profiles from shellye here - but
> the ones that have been provided are all unsymbolicated, which isn't helpful.
> 
> I wonder if that's the LTE Network hitting us here - downloading those
> symbols might just be taking a super long time.
> 
> shellye, do you have the ability to test the performance on a different
> network to see if that changes the behaviour?

Pretty sure it's not LTE related as mentioned above.
(In reply to Mike Conley (:mconley) (:⚙️) from comment #54)
> Also, shellye, if you have the time, could you please provide a similar
> video as the ones for FF57 and FF56b for this build:
> 
> https://ftp.mozilla.org/pub/firefox/nightly/2017/08/2017-08-20-10-03-43-
> mozilla-central/firefox-57.0a1.en-US.win32.zip

Is this the same build just before the new loading indicator?
Seems like I tested this, will try again just for your satisfaction,
Should it be done on the fast or slow as have both.

Comment 56

[u595893]

Yes this build is snappy even on the lower machine,
On same network today's build is lag ridden.

Comment 57

[u595893]

Should the video be made?

The build you linked is super snappy in rendering the pages and CPU/Gpu usage is normal,
Today's nightly is Spiking the thing like crazy and pretty unusable in the slow machine,
you first observation and moss-regression both are right,
It's the slow machine which led to testing the 32bit version on this machine,

If you still are in doubt then will make a video just for you ...

Comment 58

[u595893]

Attachment: FF57 linked on low specs machine

No spikes in CPU/GPu use and rendered pretty fast

Comment 59

[u595893]

Attachment: FF57 today's build on same setup

The Loading indicators are killing my machine CPU fans churning at full speed.

Comment 60

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #53)

> shellye, do you have the ability to test the performance on a different
> network to see if that changes the behaviour?
the above videos,
Both the test's were on a different network.
The the difference is huge, if opened a few more bookmarks the computer will freeze due to load in FF57,
The lined build can handle any number thrown at it...

Comment 61

[Mike Conley (:mconley) (:⚙️)]

(In reply to shellye from comment #60)
> Both the test's were on a different network.
> The the difference is huge, if opened a few more bookmarks the computer will
> freeze due to load in FF57,
> The lined build can handle any number thrown at it...

Okay, great, thank you shellye.

We understand that the new throbber appears to be impacting your browser performance. We're in the process of trying to understand why - that's the most important part, and will influence how we fix it.

We're hoping we can put together a few test builds with various solutions for you to try - we hope you're willing to help us test them!

Along with that, I have another experiment for you to try; in a build with the new throbber, can you please go to about:config and set nglayout.debug.paint_flashing_chrome to true, and then do (yet) another screen recording with the bad build and post it?

Finally, on your school network, with the better network, would you be able to try to gather a performance profile there using the Gecko Profiler Add-on? I wonder if you'll have better success in producing a symbolicated profile that way. Try to make sure that there's no "symbolicating" message being displayed at the top of the page when you Share it. Thanks!

Comment 62

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #61)
> (In reply to shellye from comment #60)
> > Both the test's were on a different network.
> > The the difference is huge, if opened a few more bookmarks the computer will
> > freeze due to load in FF57,
> > The lined build can handle any number thrown at it...
> 
> Okay, great, thank you shellye.
> 
> We understand that the new throbber appears to be impacting your browser
> performance. We're in the process of trying to understand why - that's the
> most important part, and will influence how we fix it.
> 
> We're hoping we can put together a few test builds with various solutions
> for you to try - we hope you're willing to help us test them!
> 

Sure !

> Along with that, I have another experiment for you to try; in a build with
> the new throbber, can you please go to about:config and set
> nglayout.debug.paint_flashing_chrome to true, and then do (yet) another
> screen recording with the bad build and post it?
> 

OK

> Finally, on your school network, with the better network, would you be able
> to try to gather a performance profile there using the Gecko Profiler
> Add-on? I wonder if you'll have better success in producing a symbolicated
> profile that way. Try to make sure that there's no "symbolicating" message
> being displayed at the top of the page when you Share it. Thanks!

Can try but can't seem to get it done yet.

Comment 63

[Mike Conley (:mconley) (:⚙️)]

Putting the ni? back on shellye for that screen recording and the Gecko Profile.

Comment 64

[u595893]

Attachment: Flashing

Comment 65

[u595893]

Fingers crossed

https://perfht.ml/2wOllox

Comment 66

[u595893]

Double Fingers crossed

https://perfht.ml/2wOo3ul


Can a try build be provided without any throbbers or animations?
Just to see if make any significant difference please?

Comment 67

[Gary [:streetwolf52]]

Is this only 32bit Nightly?  I am getting something similar on 64 bit Nightly.  When you go to the following site you will still a spinner well spinning.  Doesn't do that in safe-mode or in MS Edge.  You might need to log in the site to use it.  I'm on Windows 10 Pro 64 bit.

https://answers.microsoft.com/en-us/newthread?threadtype=Questions&cancelurl=%2Fen-us

Comment 68

[u595893]

(In reply to Gary [:streetwolf] from comment #67)
> Is this only 32bit Nightly?  I am getting something similar on 64 bit
> Nightly.  When you go to the following site you will still a spinner well
> spinning.  Doesn't do that in safe-mode or in MS Edge.  You might need to
> log in the site to use it.  I'm on Windows 10 Pro 64 bit.
> 
> https://answers.microsoft.com/en-us/
> newthread?threadtype=Questions&cancelurl=%2Fen-us

page working fine on 32bit Nightly on Linux/Windows

Comment 69

[Gary [:streetwolf52]]

Either my problem on the page I cited is unique to me and has nothing to do with this bug or perhaps my configuration is different than yours. Perhaps graphic stuff.  Anywho I've noticed getting the spinner on random sites intermittently for a week or so.

Comment 70

[Gary [:streetwolf52]]

My particular problem appears to be caused by the add-on bitwarden.  I'm in contact with the developer.

Comment 71

[Jared Wein [:jaws] (please needinfo? me)]

shellye, here's links to test builds:

APNG (make sure to set toolkit.cosmeticAnimations.enabled=false in about:config):
-------------------------
Linux x64: https://queue.taskcluster.net/v1/task/HrMKYp5XR1m19-iErNa6cw/runs/0/artifacts/public/build/target.tar.bz2
OSX: https://queue.taskcluster.net/v1/task/SeOjw-WKQ2auusuWX4LqMA/runs/0/artifacts/public/build/target.dmg
Windows x64: https://queue.taskcluster.net/v1/task/c9I5SnEORfK5WDnvjXr6qw/runs/0/artifacts/public/build/target.zip
Windows x32: https://queue.taskcluster.net/v1/task/W1e6B3pUQXed3IRJnHVb0Q/runs/0/artifacts/public/build/target.zip
-------------------------

30fps SVG animation (no need to change any prefs):
-------------------------
Linux x64: https://queue.taskcluster.net/v1/task/NaPxPHWCTZyr6aV1ogYnag/runs/0/artifacts/public/build/target.tar.bz2
OSX: https://queue.taskcluster.net/v1/task/Te-A61NmSmmtPH2bW4mj5Q/runs/0/artifacts/public/build/target.dmg
Windows x64: https://queue.taskcluster.net/v1/task/DRgQfpJKSWecTLKLSIGQ7g/runs/0/artifacts/public/build/target.zip
Windows x32: https://queue.taskcluster.net/v1/task/BdVEM7M-RA69uGF1f-Smbg/runs/0/artifacts/public/build/target.zip

Comment 72

[Mike Conley (:mconley) (:⚙️)]

The profile in comment 66 has symbols! I can work with that.

I'm starting to suspect that what we're seeing here is thread starvation. We're not doing anything to prioritize any of our threads (see bug 1366358 for that work), and when you load a bunch of pages like that simultaneously, we spawn a bunch of content processes, and then each of those content processes spawns a bunch of threads to process the pages you're loading simultaneously.

There are certain high-priority threads (example, compositor, main threads) that aren't given actual special status from the OS, so I think the OS can choose not to service them while other threads are consuming CPU cores.

The 60fps throbbers might cause the compositor thread to wake up more often, and I wonder if that's the one that's breaking the camels back here, and starving other threads.

Hey ehsan, does my analysis seem sound?

Comment 73

[u595893]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #71)
> shellye, here's links to test builds:
> 
> APNG (make sure to set toolkit.cosmeticAnimations.enabled=false in
> about:config):
> -------------------------
> Linux x64:
> https://queue.taskcluster.net/v1/task/HrMKYp5XR1m19-iErNa6cw/runs/0/
> artifacts/public/build/target.tar.bz2
> OSX:
> https://queue.taskcluster.net/v1/task/SeOjw-WKQ2auusuWX4LqMA/runs/0/
> artifacts/public/build/target.dmg
> Windows x64:
> https://queue.taskcluster.net/v1/task/c9I5SnEORfK5WDnvjXr6qw/runs/0/
> artifacts/public/build/target.zip
> Windows x32:
> https://queue.taskcluster.net/v1/task/W1e6B3pUQXed3IRJnHVb0Q/runs/0/
> artifacts/public/build/target.zip
> -------------------------
> 
> 30fps SVG animation (no need to change any prefs):
> -------------------------
> Linux x64:
> https://queue.taskcluster.net/v1/task/NaPxPHWCTZyr6aV1ogYnag/runs/0/
> artifacts/public/build/target.tar.bz2
> OSX:
> https://queue.taskcluster.net/v1/task/Te-A61NmSmmtPH2bW4mj5Q/runs/0/
> artifacts/public/build/target.dmg
> Windows x64:
> https://queue.taskcluster.net/v1/task/DRgQfpJKSWecTLKLSIGQ7g/runs/0/
> artifacts/public/build/target.zip
> Windows x32:
> https://queue.taskcluster.net/v1/task/BdVEM7M-RA69uGF1f-Smbg/runs/0/
> artifacts/public/build/target.zip

Testing them just give me sometime(In reply to Mike Conley (:mconley) (:⚙️) from comment #72)
> The profile in comment 66 has symbols! I can work with that.
> 
> I'm starting to suspect that what we're seeing here is thread starvation.
> We're not doing anything to prioritize any of our threads (see bug 1366358
> for that work), and when you load a bunch of pages like that simultaneously,
> we spawn a bunch of content processes, and then each of those content
> processes spawns a bunch of threads to process the pages you're loading
> simultaneously.
> 
> There are certain high-priority threads (example, compositor, main threads)
> that aren't given actual special status from the OS, so I think the OS can
> choose not to service them while other threads are consuming CPU cores.
> 
> The 60fps throbbers might cause the compositor thread to wake up more often,
> and I wonder if that's the one that's breaking the camels back here, and
> starving other threads.
> 
> Hey ehsan, does my analysis seem sound?

was wondering if the 60FPS throbbers were taking the CPU/GPU to extreme load hence the slow down

Comment 74

[u595893]

Quick feedback

on x32 Linux the APNG are working way way better,
not so much the 30FPS ones.

will test on windows later today, can you guys help if have some issues?

For one noticed these builds on startup take high CPU for good 30 sec, maybe because it's testing build.

@mike can you try the comment 65 one? It's was slowing the symptoms more clearly.

Comment 75

[u595893]

After 6 hours or so of debugging on 3 different machines with various configs and OS

Found another issue and have a theory on this bug.

Comment 76

[Mike Conley (:mconley) (:⚙️)]

(In reply to shellye from comment #74)
> 
> @mike can you try the comment 65 one? It's was slowing the symptoms more
> clearly.

I'm afraid the profile in comment 65 has no symbols.

Comment 77

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to shellye from comment #74)
> Quick feedback
> 
> on x32 Linux the APNG are working way way better,
> not so much the 30FPS ones.
> will test on windows later today, can you guys help if have some issues?

Thanks, any results after testing on Windows?

> For one noticed these builds on startup take high CPU for good 30 sec, maybe
> because it's testing build.

I'm not sure why this would be. What profile are you using?

Comment 78

[u595893]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #77)
> (In reply to shellye from comment #74)
> > Quick feedback
> > 
> > on x32 Linux the APNG are working way way better,
> > not so much the 30FPS ones.
> > will test on windows later today, can you guys help if have some issues?
> 
> Thanks, any results after testing on Windows?

Yes 
The APNG throbbers solved excessive usage significantly, quite less CPU/GPU on slow machines
compared to 30FPS SVG & 60FPS svg versions.
But have you optimized them fully? seems to still take 5-15% more than the circle throbbers.

> > For one noticed these builds on startup take high CPU for good 30 sec, maybe
> > because it's testing build.
> 
> I'm not sure why this would be. What profile are you using?

Linux 32 bit fresh profile.

@mike @jaws

There are two more bugs(other than this one) but don't want to spam this bug because it's
about fall back indicators,
But the other two bugs are also related to some of the issues mentioned in this bug when it comes to 60FPS throbbers + Apng ones's and rendering pages slowly while spiking cpu/gpu which also affect the performance of the throbbers.

Comment 79

[u595893]

do you guys have access to slow machines?
if so then have a experiment to try for you guys, you guys will wanna try it because its related to power,efficiency and Perceived performance .

right way will be filing a new bug for it or doing it here?

Comment 80

[u595893]

> I'm starting to suspect that what we're seeing here is thread starvation.
> We're not doing anything to prioritize any of our threads (see bug 1366358
> for that work), and when you load a bunch of pages like that simultaneously,
> we spawn a bunch of content processes, and then each of those content
> processes spawns a bunch of threads to process the pages you're loading
> simultaneously.
> 
> There are certain high-priority threads (example, compositor, main threads)
> that aren't given actual special status from the OS, so I think the OS can
> choose not to service them while other threads are consuming CPU cores.
> 
> The 60fps throbbers might cause the compositor thread to wake up more often,
> and I wonder if that's the one that's breaking the camels back here, and
> starving other threads.
> 
> Hey ehsan, does my analysis seem sound?

Firefox 55 is the best performer,
APNG builds are close but not that great,
30 Fps SVG versions are no where near the above two,
60 Fps SVG versions now can easily lock the browser until loading finishes.

So @mike your assumptions might be right, did more tests on a different machine with similar config to photon reference hardware for Firefox 57
in Bug 1398600

You might want to look at it.

Comment 81

[u595893]

Regarding the prioritize of threads,
Isn't the easiest way to check it is turning E10s off?
Did that in that bug

Comment 82

[Mike Conley (:mconley) (:⚙️)]

shellye, can you tell me about other software that's running at the same time on this machine? Is there security software, or something like "World Community Grid" running in the background?

Comment 83

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #82)
> shellye, can you tell me about other software that's running at the same
> time on this machine? Is there security software, or something like "World
> Community Grid" running in the background?

The defaults windows 10 config, windows defender disabled,
no other software(note did reinstall windows and *only* installed Firefox just to be sure)

Comment 84

[Mike Conley (:mconley) (:⚙️)]

I spent a few hours yesterday trying to reproduce this on 3 Windows 10 machines. I was not able to detect a significant difference in page loading time when comparing the 60fps tab throbber with the APNG throbber.

shellye, would you be willing to connect over Skype or some other video chat software so I can work with you on finding some solid STR?

Comment 85

[Mike Conley (:mconley) (:⚙️)]

If you have the time, can you also repeat the experiment with the following prefs flipped:

layers.mlgpu.enabled flipped to false
layers.acceleration.disabled flipped to true

and report back?

Comment 86

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #84)
> I spent a few hours yesterday trying to reproduce this on 3 Windows 10
> machines. I was not able to detect a significant difference in page loading
> time when comparing the 60fps tab throbber with the APNG throbber.
> 
> shellye, would you be willing to connect over Skype or some other video chat
> software so I can work with you on finding some solid STR?

Don't use them,

Team-viewer can be an option
but will have to see when as don't always have the machines...

(In reply to Mike Conley (:mconley) (:⚙️) from comment #85)
> If you have the time, can you also repeat the experiment with the following
> prefs flipped:
> 
> layers.mlgpu.enabled flipped to false
> layers.acceleration.disabled flipped to true
> 
> and report back?

Give a few mins...

Comment 87

[u595893]

No difference,
disabling e10s makes difference a bit,

Just tried to check a made it occur on a pretty low machine

1.5 ghz & 2GB ram

Comment 88

[Mike Conley (:mconley) (:⚙️)]

Let's stick with a single machine for testing to avoid confusion.

Can you please post the Windows system information for the machine that you're testing in this bug? For clarity, I asked for something similar in bug 1398600 comment 9.

Comment 89

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #88)
> Let's stick with a single machine for testing to avoid confusion.

can do on both but like mentioned one has been freshly reinstalled so has nothing setup
on the other have setup, since both have same issue you can test on any,
email?
> Can you please post the Windows system information for the machine that
> you're testing in this bug? For clarity, I asked for something similar in
> bug 1398600 comment 9.

on it,
if you want to connect through temviewer to see can do that

Comment 90

[Markus Stange [:mstange]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #85)
> If you have the time, can you also repeat the experiment with the following
> prefs flipped:
> 
> layers.mlgpu.enabled flipped to false
> layers.acceleration.disabled flipped to true

These two prefs need to be flipped and tested individually. If layers.acceleration.disabled is set to true, layers.mlgpu.enabled won't make a difference.

Comment 91

[u595893]

(In reply to Markus Stange [:mstange] from comment #90)
> (In reply to Mike Conley (:mconley) (:⚙️) from comment #85)
> > If you have the time, can you also repeat the experiment with the following
> > prefs flipped:
> > 
> > layers.mlgpu.enabled flipped to false
> > layers.acceleration.disabled flipped to true
> 
> These two prefs need to be flipped and tested individually. If
> layers.acceleration.disabled is set to true, layers.mlgpu.enabled won't make
> a difference.

Oh okay flipped both at once,
testing again.

Comment 92

[u595893]

Attachment: Untitled.png

Comment 93

[u595893]

Attachment: Untitled.png

Comment 94

[u595893]

Flipped one by one with restart in between,
no improvement,
disabling e10s made the typing and tab lag disappear though

Comment 95

[Markus Stange [:mstange]]

Could you get a perf-html.io profile with e10s disabled? I'm curious to see what it looks like without the lag.

Comment 96

[u595893]

(In reply to Markus Stange [:mstange] from comment #95)
> Could you get a perf-html.io profile with e10s disabled? I'm curious to see
> what it looks like without the lag.

with Today's nightly? or APNG builds?

Have a tuff time with nightly symbol's but still giving go...

Comment 97

[Markus Stange [:mstange]]

Today's nightly.

Comment 98

[Mike Conley (:mconley) (:⚙️)]

ni? to shellye for comment 95.

Comment 99

[u595893]

Disabled e10s but there were two processes with profiler addon,
so disabled webextension.remote to make sure e10s was off
Another bug?
after disabling there was one process

Did two runs till the pages complete loading...

notice non-e10s take 30-45 seconds total where as e10s...
 

https://perfht.ml/2wnA45t

Comment 100

[u595893]

e10s one is waiting for symbols for a good few minutes,
attaching if it completes.

Comment 101

[Mike Conley (:mconley) (:⚙️)]

(In reply to shellye from comment #99)
> Disabled e10s but there were two processes with profiler addon,

The profiler doesn't show processes only, but threads within those processes. If you disabled e10s, then what you probably saw were two threads in the same single process.

Unfortunately, comment 99's profile has no symbols.

Comment 102

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #101)
> (In reply to shellye from comment #99)
> > Disabled e10s but there were two processes with profiler addon,
> 
> The profiler doesn't show processes only, but threads within those
> processes. If you disabled e10s, then what you probably saw were two threads
> in the same single process.
> 
> Unfortunately, comment 99's profile has no symbols.

:( it waited and the message dissipated and upload dialog opened.

Maybe doing it wrong.

Install nightly
install addon
import bookmarks
restart
ctrl+1
open pages 
ctrl+2

collecting data

wait a min or so
Stop profiler while current data processed

is this the way?

Comment 103

[u595893]

Attachment: Clipboard01.png

Seems to be adding something in the bottom half 
as text appear to change

but stucks for long Waiting for symbol tables for library xul.pdb... screen

Comment 104

[Mike Conley (:mconley) (:⚙️)]

(In reply to shellye from comment #103)
> but stucks for long Waiting for symbol tables for library xul.pdb... screen

Yep, it can take a while to download those symbol tables. If you're on a slower connection, the effect is amplified. I'm curious - it seems we're trying to prevent sharing of profiles until they're symbolicating (see top right corner of your screenshot)... how are you sharing the profile if symbolicating hasn't finished?

Comment 105

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #104)
> (In reply to shellye from comment #103)
> > but stucks for long Waiting for symbol tables for library xul.pdb... screen
> 
> Yep, it can take a while to download those symbol tables. If you're on a
> slower connection, the effect is amplified. I'm curious - it seems we're
> trying to prevent sharing of profiles until they're symbolicating (see top
> right corner of your screenshot)... how are you sharing the profile if
> symbolicating hasn't finished?

https://perfht.ml/2wUPoef

another try ,
see if this has symbols.

It shows upload after awhile then copies the link...

Comment 106

[u595893]

> while to download those symbol tables. 

Can the symbols be downloaded manually?

downloaded 

https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-57.0a1.en-US.win32.crashreporter-symbols.zip

extracted it, copied crashreporter-symbols to firefox directory.

?

Comment 107

[u595893]

https://perfht.ml/2wVzbW4

e10s
symbols?

Comment 108

[u595893]

e10s off

https://perfht.ml/2wX9fa9

https://perfht.ml/2wXKGtS

e10s with
trying to reproduce the lagging issues

blob:https://perf-html.io/5882b8f3-b244-44e2-a2e5-64d00cb4e5da

just look at the kb event delay of 1100ms?

while dowloading symbols speed went upto 12-14.9mbps constant then after 3mins stopped.
Whats wrong

Comment 109

[u595893]

Attachment: Firefox 2017-09-13 03.00 profile.sps.json.gz

please look at this once

Comment 110

[u595893]

https://perfht.ml/2wVnm2u

Comment 111

[Mike Conley (:mconley) (:⚙️)]

I'm afraid none of the profiles from comment 105 to comment 110 have symbols. :(

Comment 112

[u595893]

@mike don't know whats going on, was on a very fast connection.
wiping & starting with a new build.

https://perfht.ml/2y4kk9D

Created a new profile & installed profilers,imported bookmarks,capture.

connection speed test

http://beta.speedtest.net/result/6619767682

Comment 113

[u595893]

Attachment: Stuck

Always stuck here although on a fast connection, waiting for last 10mins.
No network/CPU usage...

Any help on why this is happening?


http://beta.speedtest.net/result/6620451305

Comment 114

[u595893]

Attachment: resource usage after 20 mins

Comment 115

[u595893]

Attachment: memory-report.json.gz

Comment 116

[u595893]

Attachment: console-errors-geckoprofiler.jpg

On a very fast connection,
tested on 2 different networks see links in above comments.

Comment 117

[u595893]

http://forums.mozillazine.org/viewtopic.php?f=23&t=3033366&p=14766252#p14766252


Similar issues?

Comment 118

[Mike Conley (:mconley) (:⚙️)]

(In reply to shellye from comment #113)
> Created attachment 8907565 [details]
> 
> Any help on why this is happening?

If you reload the tab with the profile in it, does it eventually succeed in symbolicating the profile?

Comment 119

[Mike Conley (:mconley) (:⚙️)]

I've had no luck reproducing the behaviour recorded in attachment 8905544 [details].

I've installed the Windows 10 Insider Preview, and I'm running 32-bit Nightly. I installed a network QOS conditioner to simulate an LTE network. I'm using the bookmarks in this bug. When I compare against the APNG build, the page loading performance is essentially the same, minus the jank in the throbbers in the APNG version due to the APNG's running on the main thread.

I'm seeing if I can downgrade from 4GB to 2GB, but I'm having trouble tracking down a 2GB stick - and at this point, I'm hoping maybe instead, I can get someone from SoftVision to help me try to reproduce this.

Hey Rares, here are the specs for a machine that shellye has been testing on:

https://bug1397092.bmoattachments.org/attachment.cgi?id=8907157

Do you have something like that in the SV lab? If so, can they run the following STR:

1) Open Firefox
2) Download https://bugzilla.mozilla.org/attachment.cgi?id=8905359 to disk
2) Open the Bookmarks Manager
3) Choose Import and Backup > Import Bookmarks from HTML to import the HTML file you downloaded in (2)
4) Find the folder you just imported, called "Test"
5) Right-click on that folder, and hover the mouse over "Open All in Tabs"
6) Get a stopwatch ready. Start the stopwatch and click "Open All in Tabs"
7) Stop the stopwatch as soon as the first new tab paints something.

If possible, please do that with Nightly, and compare against this build, which apparently paints that first new tab faster: https://queue.taskcluster.net/v1/task/W1e6B3pUQXed3IRJnHVb0Q/runs/0/artifacts/public/build/target.zip

Do you have somebody who can work with me on this, Rares?

Comment 120

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #118)
> (In reply to shellye from comment #113)
> > Created attachment 8907565 [details]
> > 
> > Any help on why this is happening?
> 
> If you reload the tab with the profile in it, does it eventually succeed in
> symbolicating the profile?

Did not try that,
will try tomorrow.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #119)
> I've had no luck reproducing the behaviour recorded in attachment 8905544 [details]
> [details].
> 
> I've installed the Windows 10 Insider Preview, and I'm running 32-bit
> Nightly. I installed a network QOS conditioner to simulate an LTE network.
> I'm using the bookmarks in this bug. When I compare against the APNG build,
> the page loading performance is essentially the same, minus the jank in the
> throbbers in the APNG version due to the APNG's running on the main thread.


Did you try disabling e10s to check the speed rendering of tabs?
Someone on suggested to go with some kind of CPU limiter app and limit the CPU since you have an i5 which is very strong. 
 
> I'm seeing if I can downgrade from 4GB to 2GB, but I'm having trouble
> tracking down a 2GB stick - and at this point, I'm hoping maybe instead, I
> can get someone from SoftVision to help me try to reproduce this.

Please inform about your finding as Stuck on Firefox55 as anything above is pretty unusable.

Comment 121

[Mike Conley (:mconley) (:⚙️)]

(In reply to shellye from comment #120)
> 
> Please inform about your finding as Stuck on Firefox55 as anything above is
> pretty unusable.

I assume you meant Firefox 56 instead of Firefox 55, correct? Firefox 56 doesn't have the SVG ping-pong throbber.

Comment 122

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #121)
> (In reply to shellye from comment #120)
> > 
> > Please inform about your finding as Stuck on Firefox55 as anything above is
> > pretty unusable.
> 
> I assume you meant Firefox 56 instead of Firefox 55, correct? Firefox 56
> doesn't have the SVG ping-pong throbber.


Yes typo.
APNG test builds with e10s off

BTW Firefox 55(old loading animation) is fine too if not mistaken(nightly till 2017-08-20 too)

Attaching the error when reloading the profiler like you suggested.

Comment 123

[u595893]

Attachment: profiler broken on 32 bit builds? or low ram machines?

Comment 124

[u595893]

Attachment: Clipboard01.jpg

One of my co workers who is an computer genius suggest's this

change maximum to 50% or less & it will lower the CPU/GPU

and then try might help as he showed me on his laptop and it worked.

Comment 125

[RaresB]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #119)
> Hey Rares, here are the specs for a machine that shellye has been testing on:
> 
> https://bug1397092.bmoattachments.org/attachment.cgi?id=8907157
> 
> Do you have something like that in the SV lab? 

Hey Mike! Sorry for the bad news, but the only PCs with AMD CPU that we're having inside SV are with a FX 8350 proc. And there's quite a difference between these two. http://cpuboss.com/cpus/AMD-FX-8350-vs-AMD-A4-4300M#differences

Is there anything else we could help with on this matter? Any other suggestions?

Comment 126

[Mike Conley (:mconley) (:⚙️)]

(In reply to shellye from comment #124)
> Created attachment 8907858 [details]
> Clipboard01.jpg
> 
> and then try might help as he showed me on his laptop and it worked.

I reduced the Maximum Processor State setting for both battery and cable in the Windows 10 performance profile from 100% to 50%, and then to 25%. In neither case could I reproduce the performance issue. I was actually quite astonished with how well Firefox behaved in this environment.

I'm curious, shellye - do you have access to a machine with a 64-bit version of Windows 10 on it? How does it behave in comparison?

Comment 127

[Mike Conley (:mconley) (:⚙️)]

shellye,

It also sounds like you're able to reproduce this issue on numerous machines. Are you able to gather symbolicated profiles from any of those machines?

Comment 128

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #126)
> (In reply to shellye from comment #124)
> > Created attachment 8907858 [details]
> > Clipboard01.jpg
> > 
> > and then try might help as he showed me on his laptop and it worked.
> 
> I reduced the Maximum Processor State setting for both battery and cable in
> the Windows 10 performance profile from 100% to 50%, and then to 25%. In
> neither case could I reproduce the performance issue. I was actually quite
> astonished with how well Firefox behaved in this environment.
> 
> I'm curious, shellye - do you have access to a machine with a 64-bit version
> of Windows 10 on it? How does it behave in comparison?

Going to download windows 10 RS3 insider 64bit (released yesterday)
and install it on the 4gb variant and see if things change.
will try to test with no drivers and then install AMD drivers to see if that's the issue.
Will let you know 

(In reply to Mike Conley (:mconley) (:⚙️) from comment #127)
> shellye,
> 
> It also sounds like you're able to reproduce this issue on numerous
> machines. Are you able to gather symbolicated profiles from any of those
> machines?

See the attachment , coworker said symbols link/url is missing or something.
can you please ask someone who knows what errors are those?
or can symbols be downloaded separately so don't have to re download?
BTW could this be AMD only issue? 
Or Win32+FF57 32bit?

Comment 129

[u595893]

Help with the Gecko profiler addon so can post links and show the issue so you guys know what's going on,
And why does e10s solve the lag for most part.

Comment 130

[u595893]

Attachment: Profiler-ERRORS.jpg

Getting these errors on different machines so don't understand.

Bug 1398600 lands soon because that and this bug make rendering slow(SVG crushes the CPU and fan whirls till pages load ),
Since Profiler is failing Don't know what else can be done,
trying everything you guys asked :(

Comment 131

[(no longer active)]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #72)
> The profile in comment 66 has symbols! I can work with that.
> 
> I'm starting to suspect that what we're seeing here is thread starvation.
> We're not doing anything to prioritize any of our threads (see bug 1366358
> for that work), and when you load a bunch of pages like that simultaneously,
> we spawn a bunch of content processes, and then each of those content
> processes spawns a bunch of threads to process the pages you're loading
> simultaneously.
> 
> There are certain high-priority threads (example, compositor, main threads)
> that aren't given actual special status from the OS, so I think the OS can
> choose not to service them while other threads are consuming CPU cores.
> 
> The 60fps throbbers might cause the compositor thread to wake up more often,
> and I wonder if that's the one that's breaking the camels back here, and
> starving other threads.
> 
> Hey ehsan, does my analysis seem sound?

Yes absolutely.  But the problem is actually worse, because our APZ code tends to block the UI thread on the compositor thread, so if our compositor thread is starved, various PAPZCTreeManager sync IPC messages on the UI thread will jank the entire UI.  :-(

I think the highest impact thing that we can do for this bug outside of the front-end is fix bug 1366353.  But even more effective is probably reverting to use something that doesn't use the compositor for the loading icon for dual core systems.  :/

Comment 132

[(no longer active)]

Sorry I don't know why I cleared mconley's ni...

Comment 133

[(no longer active)]

BTW an example of the situation I was talking about can be clearly seen in https://perfht.ml/2f7NDna.

Comment 134

[u595893]

(In reply to Out sick from comment #131)
> (In reply to Mike Conley (:mconley) (:⚙️) from comment #72)
> > The profile in comment 66 has symbols! I can work with that.
> > 
> > I'm starting to suspect that what we're seeing here is thread starvation.
> > We're not doing anything to prioritize any of our threads (see bug 1366358
> > for that work), and when you load a bunch of pages like that simultaneously,
> > we spawn a bunch of content processes, and then each of those content
> > processes spawns a bunch of threads to process the pages you're loading
> > simultaneously.
> > 
> > There are certain high-priority threads (example, compositor, main threads)
> > that aren't given actual special status from the OS, so I think the OS can
> > choose not to service them while other threads are consuming CPU cores.
> > 
> > The 60fps throbbers might cause the compositor thread to wake up more often,
> > and I wonder if that's the one that's breaking the camels back here, and
> > starving other threads.
> > 
> > Hey ehsan, does my analysis seem sound?
> 
> Yes absolutely.  But the problem is actually worse, because our APZ code
> tends to block the UI thread on the compositor thread, so if our compositor
> thread is starved, various PAPZCTreeManager sync IPC messages on the UI
> thread will jank the entire UI.  :-(
> 
> I think the highest impact thing that we can do for this bug outside of the
> front-end is fix bug 1366353.  But even more effective is probably reverting
> to use something that doesn't use the compositor for the loading icon for
> dual core systems.  :/

Just a quick question,

So that's is the reason for slow typing when pages are loading, scrolling in pages or slow switching of tabs?
and non e10s fix this lag except the page loading times.

Any ideas for gecko profiler not working?

Get well soon and loved reading you post .

Comment 135

[u595893]

Plus the issues in Bug 1398600

Comment 136

[(no longer active)]

(In reply to shellye from comment #134)
> So that's is the reason for slow typing when pages are loading, scrolling in
> pages or slow switching of tabs?
> and non e10s fix this lag except the page loading times.

Yes, most (all?) of those operations require a sync IPC to the compositor thread, so the problem in comment 131 would affect them all.

> Any ideas for gecko profiler not working?

Not sure really.  I've seen other users who have been on slow connections have a difficult time uploading profiles due to their network connection, given comment 26 my best guess (and it's only a guess) is that is the reason unfortunately.

(In reply to shellye from comment #135)
> Plus the issues in Bug 1398600

I think your best bet to get traction on that bug is to manage to upload a profile successfully with the symbols for xul.dll and post it on the bug.  I realize that it's been difficult for you, but sadly there's very little that can be done by us effectively without a profile.

> Get well soon and loved reading you post .

Thank you.  :-)

Comment 137

[Mike Conley (:mconley) (:⚙️)]

I _may_ have just reproduced this issue, but I had to drop the priority of the Compositor process to Low in the Windows Task Manager.

shellye, I have an experiment for you to try: can you please re-run the STR, but before that:

0) Start up the Firefox instance.
1) Go to about:support, and find the Graphics section
2) Find the GPU process PID. It's near the bottom of the Graphics section.
3) Open up the Windows Task Manager, and in the Details tab, find the process with that PID.
4) Right-click on that process, and choose Set priority > High
5) Re-run the experiment

Does that change the behavior at all?

Comment 138

[Jared Wein [:jaws] (please needinfo? me)]

shellye, can you open up the Browser Console and execute the following line:

> `Services.sysinfo.getProperty("cpucores")`

and paste the result here? You may need to enable "browser chrome and add-on debugging toolboxes". To do this, open the Developer Tools and go to Settings, then check the associated checkbox. Here's a screenshot, https://www.screencast.com/t/KekdO2kYAb

Comment 139

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #137)
> I _may_ have just reproduced this issue, but I had to drop the priority of
> the Compositor process to Low in the Windows Task Manager.
> 
> shellye, I have an experiment for you to try: can you please re-run the STR,
> but before that:
> 
> 0) Start up the Firefox instance.
> 1) Go to about:support, and find the Graphics section
> 2) Find the GPU process PID. It's near the bottom of the Graphics section.
> 3) Open up the Windows Task Manager, and in the Details tab, find the
> process with that PID.
> 4) Right-click on that process, and choose Set priority > High
> 5) Re-run the experiment
> 
> Does that change the behavior at all?

Will try today.(In reply to (Away until Sept 19) Jared Wein [:jaws] (please needinfo? me) from comment #138)
> shellye, can you open up the Browser Console and execute the following line:
> 
> > `Services.sysinfo.getProperty("cpucores")`
> 
> and paste the result here? You may need to enable "browser chrome and add-on
> debugging toolboxes". To do this, open the Developer Tools and go to
> Settings, then check the associated checkbox. Here's a screenshot,
> https://www.screencast.com/t/KekdO2kYAb

Did and restarted then ran the command and it threw an error about command being incorrect

Comment 140

[u595893]

Attachment: Clipboard01.jpg

On a different machine with both 64 bit OS+FF

https://perfht.ml/2eYcUMI

still getting this error,
can any one point on whats going on as this seems *profiler* issue and seems profile info is very important.

Comment 141

[u595893]

(In reply to Out sick from comment #136)

> > Any ideas for gecko profiler not working?
> 
> Not sure really.  I've seen other users who have been on slow connections
> have a difficult time uploading profiles due to their network connection,
> given comment 26 my best guess (and it's only a guess) is that is the reason
> unfortunately.
>

Please see the other comments , connection was not a bottleneck as was on a very fast network

results of speedtest

http://beta.speedtest.net/result/6619767682

http://beta.speedtest.net/result/6620451305


> (In reply to shellye from comment #135)
> > Plus the issues in Bug 1398600
> 
> I think your best bet to get traction on that bug is to manage to upload a
> profile successfully with the symbols for xul.dll and post it on the bug.  I
> realize that it's been difficult for you, but sadly there's very little that
> can be done by us effectively without a profile.
>

Please point to someone who can help with the profiler as the comment above this, profiler is throwing an error
even on different pc's , maybe the profiler is broken or the steps(mentioned in Comment 102 )

> Thank you.  :-)

Looking forward to reading your posts soon(get well first)

Comment 142

[Gonzalo HIGUERA DÍAZ]

I might be experiencing something related to this issue on a mid-2012 Retina MacBook Pro running up-to-date Firefox nightlies on macOS 10.12.6 (x86-64). Caveat: my experiences leading to this bug have revolved around trying out the webextension version of Tree Style Tab (TST). When doing so, sometimes there are no ping-pong throbbers in the (normal) horizontal tabs yet for some reason some of TST's vertical tabs (which sit in the sidebar) continue to show them for a long time (in case it is version-dependant, I believe that I saw it happen fairly regularly with TST builds around the 0.19.2017090601 Git tag). When this happens the laptop's fans let me know (to me, the unwanted noise trumps whatever performance issues might also be taking place) and the CPU values from Activity Monitor show that Firefox Nightly (the main process in particular) is in the list of suspects. If I hide the TST sidebars of those windows with tab-loading indicators the CPU usage drops; if I show them again (assuming that the throbbers are still active) it jumps back up.

I practically don't use Nightly without TST so my impression that even with a clean profile there is a link between performance issues and the page-loading throbber is likely biased. (In that situation I have very rarely managed to have a tab's loading indicator ‘stuck’, and without being able to hide the usual Firefox tabs I cannot tell whether the CPU usage should be lower or not). I am sorry not to be able to provide a more solid extensionless account, but I hope that what I have shared might be somewhat relevant (or at least not misleading).

Comment 143

[u595893]

Attachment: Profiler_error.txt

This error is a profiler one, different machine with x64 linux with 4gb,
Very high speed WiFi.

Still getting this error
An unexpected error occurred  5fb3338c9233040ea039.bundle.js:25(25 is same as windows32bit)

Can someone tell what's the error it's showing mean?

No Idea how to help you all without generating the profile...

Requesting NI? for the errors and how to solve it.

Comment 144

[u595893]

(In reply to Gonzalo HIGUERA DÍAZ from comment #142)
> I might be experiencing something related to this issue on a mid-2012 Retina
> MacBook Pro running up-to-date Firefox nightlies on macOS 10.12.6 (x86-64).
> Caveat: my experiences leading to this bug have revolved around trying out
> the webextension version of Tree Style Tab (TST). When doing so, sometimes
> there are no ping-pong throbbers in the (normal) horizontal tabs yet for
> some reason some of TST's vertical tabs (which sit in the sidebar) continue
> to show them for a long time (in case it is version-dependant, I believe
> that I saw it happen fairly regularly with TST builds around the
> 0.19.2017090601 Git tag). When this happens the laptop's fans let me know
> (to me, the unwanted noise trumps whatever performance issues might also be
> taking place) and the CPU values from Activity Monitor show that Firefox
> Nightly (the main process in particular) is in the list of suspects. If I
> hide the TST sidebars of those windows with tab-loading indicators the CPU
> usage drops; if I show them again (assuming that the throbbers are still
> active) it jumps back up.
> 
> I practically don't use Nightly without TST so my impression that even with
> a clean profile there is a link between performance issues and the
> page-loading throbber is likely biased. (In that situation I have very
> rarely managed to have a tab's loading indicator ‘stuck’, and without being
> able to hide the usual Firefox tabs I cannot tell whether the CPU usage
> should be lower or not). I am sorry not to be able to provide a more solid
> extensionless account, but I hope that what I have shared might be somewhat
> relevant (or at least not misleading).

Can you provide a performance profile ( https://perf-html.io/ )

Comment 145

[u595893]

Attachment: CPU

The CPU info

Comment 146

[u595893]

Attachment: CPU1

The CPU info from another software since Jared's method did not work.

Comment 147

[Alice0775 White]

AFAIK, Using 1 or 2 older Nightly build might be solved the symbol issue of gecko profiler.

Comment 148

[u595893]

(In reply to Alice0775 White from comment #147)
> AFAIK, Using 1 or 2 older Nightly build might be solved the symbol issue of
> gecko profiler.

Thankyou Alice trying it.

Comment 149

[u595893]

Tried again using Alice's method with 13th & 14th Build
please check if it has symbols


https://perfht.ml/2wfH6hx


https://pastebin.com/dl/urTUFEzX

Comment 150

[Alice0775 White]

I am not developer, and have no idea, sorry.

Comment 151

[Alice0775 White]

And please stop ni-ing.

Comment 152

[u595893]

Downloaded FF56b12

https://perfht.ml/2xExCga

(symbols might be present but same line 25 error )
BTW it was so smooth and fast.

Comment 153

[Mike Conley (:mconley) (:⚙️)]

(In reply to shellye from comment #152)
> Downloaded FF56b12
> 
> https://perfht.ml/2xExCga
> 
> (symbols might be present but same line 25 error )
> BTW it was so smooth and fast.

Your latest profiles have symbols! That's wonderful, thank you.

Are you able to use the same machine and network to get a profile from the Nightly build from just before the ping-pong throbber landed? Here's the build you can use:

https://ftp.mozilla.org/pub/firefox/nightly/2017/08/2017-08-20-10-03-43-mozilla-central/firefox-57.0a1.en-US.win32.zip

Comment 154

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #153)
> (In reply to shellye from comment #152)
> > Downloaded FF56b12
> > 
> > https://perfht.ml/2xExCga
> > 
> > (symbols might be present but same line 25 error )
> > BTW it was so smooth and fast.
> 
> Your latest profiles have symbols! That's wonderful, thank you.
> 
> Are you able to use the same machine and network to get a profile from the
> Nightly build from just before the ping-pong throbber landed? Here's the
> build you can use:
> 
> https://ftp.mozilla.org/pub/firefox/nightly/2017/08/2017-08-20-10-03-43-
> mozilla-central/firefox-57.0a1.en-US.win32.zip

Yes same, wanted to see if can link symbols with beta,
Saw the error but since network was being used waited(normally network activity stops with FF57)
Do the profile few comments above have symbols?
Download and trying to profile it.

NOTE this build FF56b12 had no issues and only thing which found different was E10s multi + new indicators were not present.

Comment 155

[u595893]

https://perfht.ml/2xFFqhy

@mike the profile for the above build,
After using FF56b12 for 10mins or so using this build was atrocious
pages were taking ages and CPU fan started to run crazy.

Tested today's night to check and the assumption before was right, Bug 1398600 + this bug have regressed it badly

Do that experiment you mentioned before needs to be done?

Comment 156

[u595893]

https://perfht.ml/2xE2RYM


Second run with more atrocious performance

Comment 157

[Mike Conley (:mconley) (:⚙️)]

Hi shellye,

We need to focus this bug as much as possible, so I'm focusing on the regression that you originally reported where page loading times got worse when the new 60fps tab throbber landed. I'm going to ignore differences between FF56b12 and the build from before the new tab throbber landed for now in this bug. If we want to look at that, we should do that in a separate bug.

So, just to be clear: this bug is _strictly_ about any kind of performance regression that occurred once the new tab throbber landed. Other regressions should be filed and investigated separately and outside of this bug to avoid adding confusion to this bug.

Comment 158

[Mike Conley (:mconley) (:⚙️)]

That having been said(In reply to shellye from comment #155)
> https://perfht.ml/2xFFqhy
> 

Great! This profile also has symbols. So, just to confirm, this is from the build _just before_ the new tab throbber landed? The build I pointed to in comment 153?

Comment 159

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #157)
> Hi shellye,
> 
> We need to focus this bug as much as possible, so I'm focusing on the
> regression that you originally reported where page loading times got worse
> when the new 60fps tab throbber landed. I'm going to ignore differences
> between FF56b12 and the build from before the new tab throbber landed for
> now in this bug. If we want to look at that, we should do that in a separate
> bug.
> 

Okay , Please file them as have no idea what's the cause and what to file against.

> So, just to be clear: this bug is _strictly_ about any kind of performance
> regression that occurred once the new tab throbber landed. Other regressions
> should be filed and investigated separately and outside of this bug to avoid
> adding confusion to this bug.

But until you find the other bug/issue how can we separate whats due to new loading throbber and what is before?
Because both are pretty severe bugs causing CPU usage jump and landed in the same timeline.


(In reply to Mike Conley (:mconley) (:⚙️) from comment #158)
> That having been said(In reply to shellye from comment #155)
> > https://perfht.ml/2xFFqhy
> > 
> 
> Great! This profile also has symbols. So, just to confirm, this is from the
> build _just before_ the new tab throbber landed? The build I pointed to in
> comment 153?

YES.

https://perfht.ml/2xEIcE0

today's build( even worse :/ )

Comment 160

[Mike Conley (:mconley) (:⚙️)]

(In reply to shellye from comment #159)
> But until you find the other bug/issue how can we separate whats due to new
> loading throbber and what is before?
> Because both are pretty severe bugs causing CPU usage jump and landed in the
> same timeline.
> 

We do this by only testing only a strict set of builds: ideally, the build just before the new throbber landed, and the one just after. Your bisection pointed at the tab throbber, so we're trusting that this is the case. The profiles that you've provided will now hopefully help us derive how the new tab throbber is affecting page load performance.

Comment 161

[Mike Conley (:mconley) (:⚙️)]

So, for the folks watching at home, here are the profiles we care about:

Pre-regression: https://perfht.ml/2xFFqhy
Post-regression: https://perfht.ml/2wfH6hx

Comment 162

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #160)
> (In reply to shellye from comment #159)
> > But until you find the other bug/issue how can we separate whats due to new
> > loading throbber and what is before?
> > Because both are pretty severe bugs causing CPU usage jump and landed in the
> > same timeline.
> > 
> 
> We do this by only testing only a strict set of builds: ideally, the build
> just before the new throbber landed, and the one just after. Your bisection
> pointed at the tab throbber, so we're trusting that this is the case. The
> profiles that you've provided will now hopefully help us derive how the new
> tab throbber is affecting page load performance.

Okay got it, please file the other bug when you are free so it's gets fixed in time for FF57.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #161)
> So, for the folks watching at home, here are the profiles we care about:
> 
> Pre-regression: https://perfht.ml/2xFFqhy
> Post-regression: https://perfht.ml/2wfH6hx

Hmm did another try with the trying to reproduce this issues

https://perfht.ml/2xFTyHC

since was related to scrolling lag and had read apz scroll was enable for keyboard
set 
input_event_queue.supported;false

only changed this but seems you got the things you needed already.

Comment 163

[(no longer active)]

(In reply to shellye from comment #141)
> (In reply to Out sick from comment #136)
> 
> > > Any ideas for gecko profiler not working?
> > 
> > Not sure really.  I've seen other users who have been on slow connections
> > have a difficult time uploading profiles due to their network connection,
> > given comment 26 my best guess (and it's only a guess) is that is the reason
> > unfortunately.
> >
> 
> Please see the other comments , connection was not a bottleneck as was on a
> very fast network

Like I said, that was just a guess.  :-)

> Please point to someone who can help with the profiler as the comment above
> this, profiler is throwing an error
> even on different pc's , maybe the profiler is broken or the steps(mentioned
> in Comment 102 )

The profiler is working fine.  The errors you are seeing on Windows in the screenshot and the text file you posted are telling you that we don't have access to the debug symbols for some private Microsoft DLLs, but that should be OK, and on Linux they're telling you that you don't have the debug symbol packages for those libraries installed, but again that should be fine.  The way we tell whether a profile is useful to us is by looking at it and seeing whether the symbols for xul.dll/libxul.so are present which is where the majority of the code for Firefox lives.  Looking at the Browser Console output is a particularly bad way determining whether a profile is useful!  At any rate it seems like now you can successfully upload symbolicated profiles.  :-)

Also, if I may suggest something, it's not considered good form to excessively needinfo people on Bugzilla.  needinfo is used by us as a way to flag someone for something specific when we can't make progress on something important, but for normal comments on bugs just commenting and waiting for people to get back to you works just as well.  Perhaps it's a non-obvious cultural thing at Mozilla, but I suggest using the needinfo flag *very* occasionally only when there an important issue is blocked on something specific that somebody knows.  :-)

(In reply to shellye from comment #156)
> https://perfht.ml/2xE2RYM

FWIW I filed bug 1400294 from this profile but that isn't the main root cause of the performance issues you're experiencing.

Comment 164

[Mike Conley (:mconley) (:⚙️)]

Hi shellye,

Myself and few other engineers spent some time examining the profiles you posted today. We recorded a video of ourselves doing that if you're curious to see the process:

https://air.mozilla.org/the-joy-of-profiling-episode-11/

One thing from your profiles caught our attention:

It _looks_ like your compositor process is using D3D11 WARP, which is a software compositor, and skipping the GPU entirely. We're not 100% sure this is the case, and have some things we'd like you to try to be sure, but this might explain the issue; we're accidentally stressing your CPU when we _think_ we're okay to stress your GPU. The 60fps tab throbbers might be pushing you over the edge there. This might occur because our graphics infrastructure is having a hard time recognizing your GPU (note the missing device ID in the posted about:support from comment 27).

To test this, we need you to get the badly performing Nightly to crash intentionally, and then send us a link to the crash report. The report should contain a list of all of the DLLs that were loaded at the time of the crash. If we don't see your GPU drivers in that list, then it greatly strengthens the hypothesis that we're skipping your GPU altogether, and this could explain the stress on your 2-core CPU (and the thread starvation).

Here's how you can crash your Nightly intentionally:

1. Download https://ftp.mozilla.org/pub/utilities/crashfirefox-intentionally/crashfirefox.exe (this is the 32-bit version)
2. Run the badly performing Nightly, and perhaps run your STR just to make sure all of the appropriate DLLs are loaded
3. From the command line, run crashfirefox.exe. This should cause the entire browser to crash.
4. When the crash reporter dialog comes up, choose to submit the report (noting the time of day), and restart Nightly
5. Once Nightly restarts, go to about:crashes
6. In about:crashes, find the Submitted Crash Report that roughly corresponds to the time of day when you submitted your report. Right click on that crash report, and paste the link into this bug.

If you have the time, we'd also like you to re-run your STR with dom.ipc.processCount set to 1, and then to 2, and post profiles from those runs for comparison.

Thanks so much for your patience and information here.

Comment 165

[Gonzalo HIGUERA DÍAZ]

(In reply to shellye from comment #144)
> Can you provide a performance profile ( https://perf-html.io/ )

Given the latter comments, I downloaded the sequential nightly builds 2017-08-21-10-03-50 and 2017-08-22-10-05-29 (circular and horizontal tab-loading throbbers respectively). The Tree Style Tab webextension does not work on them: the sidebar appears empty with a ping-pong throbber, and while this sidebar is visible Activity Monitor show 100% CPU usage by the main Nightly process (otherwise it is sub-10%). I don't want to add noise to this discussion given that this behaviour seems to deviate from the specific issues towards where this bug report is heading, so unless told otherwise I will step aside.

Comment 166

[u595893]

(In reply to Out sick from comment #163)
> (In reply to shellye from comment #141)
> > (In reply to Out sick from comment #136)
> > 
> > > > Any ideas for gecko profiler not working?
> > > 
> > > Not sure really.  I've seen other users who have been on slow connections
> > > have a difficult time uploading profiles due to their network connection,
> > > given comment 26 my best guess (and it's only a guess) is that is the reason
> > > unfortunately.
> > >
> > 
> > Please see the other comments , connection was not a bottleneck as was on a
> > very fast network
> 
> Like I said, that was just a guess.  :-)
> 
> > Please point to someone who can help with the profiler as the comment above
> > this, profiler is throwing an error
> > even on different pc's , maybe the profiler is broken or the steps(mentioned
> > in Comment 102 )
> 
> The profiler is working fine.  The errors you are seeing on Windows in the
> screenshot and the text file you posted are telling you that we don't have
> access to the debug symbols for some private Microsoft DLLs, but that should
> be OK, and on Linux they're telling you that you don't have the debug symbol
> packages for those libraries installed, but again that should be fine.  The
> way we tell whether a profile is useful to us is by looking at it and seeing
> whether the symbols for xul.dll/libxul.so are present which is where the
> majority of the code for Firefox lives.  Looking at the Browser Console
> output is a particularly bad way determining whether a profile is useful! 
> At any rate it seems like now you can successfully upload symbolicated
> profiles.  :-)
> 

Had no idea

> Also, if I may suggest something, it's not considered good form to
> excessively needinfo people on Bugzilla.  needinfo is used by us as a way to
> flag someone for something specific when we can't make progress on something
> important, but for normal comments on bugs just commenting and waiting for
> people to get back to you works just as well.  Perhaps it's a non-obvious
> cultural thing at Mozilla, but I suggest using the needinfo flag *very*
> occasionally only when there an important issue is blocked on something
> specific that somebody knows.  :-)
>

OK had no idea and @mike & @jaws NI? me frequently to test or experiment so thought that's the way, and apologize for it.
 
> (In reply to shellye from comment #156)
> > https://perfht.ml/2xE2RYM
> 
> FWIW I filed bug 1400294 from this profile but that isn't the main root
> cause of the performance issues you're experiencing.

Okay *Just* to be clear..

It's a combination of three issue,
1)loading indicator spiking cpu and rendering times.
2)Rendering times with UI sluggishness when interacting with content or UI
3)Scrolling delayed or scrolls after a few seconds during loading. 


Again sorry for the mistake had no idea how to use it.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #164)
> Hi shellye,
> 
> Myself and few other engineers spent some time examining the profiles you
> posted today. We recorded a video of ourselves doing that if you're curious
> to see the process:
> 
> https://air.mozilla.org/the-joy-of-profiling-episode-11/
> 
> One thing from your profiles caught our attention:
> 
> It _looks_ like your compositor process is using D3D11 WARP, which is a
> software compositor, and skipping the GPU entirely. We're not 100% sure this
> is the case, and have some things we'd like you to try to be sure, but this
> might explain the issue; we're accidentally stressing your CPU when we
> _think_ we're okay to stress your GPU. The 60fps tab throbbers might be
> pushing you over the edge there. This might occur because our graphics
> infrastructure is having a hard time recognizing your GPU (note the missing
> device ID in the posted about:support from comment 27).

@mike not sure but mentioned it before that reinstalled win10 and will test on it before installing driver's just to see if drivers were the cause!
Do you remember?
 Comment 89
> 
> To test this, we need you to get the badly performing Nightly to crash
> intentionally, and then send us a link to the crash report. The report
> should contain a list of all of the DLLs that were loaded at the time of the
> crash. If we don't see your GPU drivers in that list, then it greatly
> strengthens the hypothesis that we're skipping your GPU altogether, and this
> could explain the stress on your 2-core CPU (and the thread starvation).
> 

Happened before with AMD driver's too so that's not it but if you guys still want it will install the drivers and do it.
IF yes will you be online in 30 mins?

will install and try crashing it.

> Here's how you can crash your Nightly intentionally:
> 
> 1. Download
> https://ftp.mozilla.org/pub/utilities/crashfirefox-intentionally/
> crashfirefox.exe (this is the 32-bit version)
> 2. Run the badly performing Nightly, and perhaps run your STR just to make
> sure all of the appropriate DLLs are loaded
> 3. From the command line, run crashfirefox.exe. This should cause the entire
> browser to crash.
> 4. When the crash reporter dialog comes up, choose to submit the report
> (noting the time of day), and restart Nightly
> 5. Once Nightly restarts, go to about:crashes
> 6. In about:crashes, find the Submitted Crash Report that roughly
> corresponds to the time of day when you submitted your report. Right click
> on that crash report, and paste the link into this bug.
> 
> If you have the time, we'd also like you to re-run your STR with
> dom.ipc.processCount set to 1, and then to 2, and post profiles from those
> runs for comparison.
> 

FYI it was one, mentioned it when you asked to experiment with 2 instead of 4

But will do again.

> Thanks so much for your patience and information here.

NO THANK YOU!
Most people did not understand if what was in the bug report was true, you had faith , guided to do things, try things,
and finally it was you that kept on asking to experiment otherwise this would have been a dead end.

Comment 167

[u595893]

@mike are you sure? 
about doing the crashing and drivers?

Profiler is working after all this so if it breaks?

Or create a new profile and crash it?
or any other way?

Comment 168

[Mike Conley (:mconley) (:⚙️)]

(In reply to shellye from comment #167)
> @mike are you sure? 
> about doing the crashing and drivers?
> 
> Profiler is working after all this so if it breaks?
> 
> Or create a new profile and crash it?
> or any other way?

For the crashing experiment, it is not necessary to generate a profile, so you can skip the creating a profile step for that particular bit of data.

Comment 169

[u595893]

https://crash-stats.mozilla.com/report/index/21b7615c-9e21-45d4-8cc2-230190170915

Comment 170

[u595893]

https://crash-stats.mozilla.com/report/index/5fdb1ffd-5a6a-4b3a-a620-4d5090170915

Comment 171

[u595893]

@mike anything else?

heads up Going to reinstall windows 10 in next 24hrs new RS3(final beta)

Comment 172

[Mike Conley (:mconley) (:⚙️)]

(In reply to shellye from comment #171)
> @mike anything else?
> 

Yes, please. We've examined the crash stacks, and we have more questions - but in order to get them, we need to know more about your graphics drivers. Can you please set:

layers.gpu-process.enabled

to false, restart the browser, and re-crash the browser after running your experiment again?

It's also important to ensure that once you've done these experiments that you re-set your prefs back. Please ensure, for example, that the prefs from comment 85 have also been reset to their default state.

Thank you!

Comment 173

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #172)
> (In reply to shellye from comment #171)
> > @mike anything else?
> > 
> 
> Yes, please. We've examined the crash stacks, and we have more questions -
> but in order to get them, we need to know more about your graphics drivers.
> Can you please set:
> 
> layers.gpu-process.enabled
> 
> to false, restart the browser, and re-crash the browser after running your
> experiment again?
> 
> It's also important to ensure that once you've done these experiments that
> you re-set your prefs back. Please ensure, for example, that the prefs from
> comment 85 have also been reset to their default state.
> 
> Thank you!

Doing it and attaching the link.

@mike just a question do you think this can be solved before bug 1398600 as the build you link above has the poor performance but
new loading indicators make it 10x worse,
so shouldn't that be examined first?

Comment 174

[u595893]

https://crash-stats.mozilla.com/report/index/9a853e1e-7cdb-4dc2-9682-c41af0170916

Comment 175

[u595893]

@jaws reinstalled latest w10 with nothing else to test 

the APNG profile

of the test build

https://perfht.ml/2xrdRrG

& today's nightly with svg indicators

e10s off

https://perfht.ml/2xqCdBy

e10s on with 1 process(bonus typing lag in it)

https://perfht.ml/2xqLnxV

In both run this was off

toolkit.cosmeticAnimations.enabled;false

Please also see comment 173(and the bug for other tests before this new loading animation)

Comment 176

[Mike Conley (:mconley) (:⚙️)]

Hey shellye,

This is getting curiouser and curiouser. The profiles you provided seem to be at odds with the profiles in terms of what graphics subsystem is being used. We have yet another experiment for you to try - thank you so much for your patience here.

Can you please gather another profile, this time with 1 content process, and the GPU process disabled (just like you did when you gathered that crash report).

Comment 177

[Mike Conley (:mconley) (:⚙️)]

> The profiles you provided seem to
> be at odds with the profiles

Sorry, this hsould be "The profiles you provided seem to be at odds with the crash report"

Comment 178

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #176)
> Hey shellye,
> 
> This is getting curiouser and curiouser. The profiles you provided seem to
> be at odds with the profiles in terms of what graphics subsystem is being
> used. We have yet another experiment for you to try - thank you so much for
> your patience here.
> 
> Can you please gather another profile, this time with 1 content process, and
> the GPU process disabled (just like you did when you gathered that crash
> report).

OK

Did you mean 

layers.mlgpu.enabled
or
layers.gpu-process.enabled

What exactly needs to be done?
Gecko profiler and then crash?

Comment 179

[u595893]

Latest AMD/ATI drivers

layers.gpu-process.enabled false

1 process(everything else was same)

FF57(Today's Nightly)
https://perfht.ml/2jGhYL9


FF56b12
https://perfht.ml/2jGL7pw


@mike due to a sad incident(involving a relative) would not be able to come online for next 10 or so days,
if you have anything else please ask in next 5-6 hours else wait 10 days.

Sorry but in no condition to reply so did what you had asked.
Sorry.

Comment 180

[Mike Conley (:mconley) (:⚙️)]

(In reply to shellye from comment #179)
> @mike due to a sad incident(involving a relative) would not be able to come
> online for next 10 or so days,
> if you have anything else please ask in next 5-6 hours else wait 10 days.
> 

I'm very sorry to hear that. :( I hope things turn out okay. There's no rush here, absolutely do what you need to do.

If, however, you have the free time and inclination, we're like you to try an experiment:

1) Disable the Gecko Profiler Add-on
2) Disable the GPU process again (set layers.gpu-process.enabled to false)
3) Disable Extended Telemetry (set toolkit.telemetry.enabled to false)

Restart the browser, and repeat your experiment. Does the performance improve? If so, this would strengthen the thread starvation hypothesis.

Comment 181

[Mike Conley (:mconley) (:⚙️)]

Also, out of curiosity, you haven't accidentally set layers.d3d11.force-warp to true at any point, have you?

Comment 182

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #180)
> (In reply to shellye from comment #179)
> > @mike due to a sad incident(involving a relative) would not be able to come
> > online for next 10 or so days,
> > if you have anything else please ask in next 5-6 hours else wait 10 days.
> > 
> 
> I'm very sorry to hear that. :( I hope things turn out okay. There's no rush
> here, absolutely do what you need to do.
> 

Ty

> If, however, you have the free time and inclination, we're like you to try
> an experiment:
> 
> 1) Disable the Gecko Profiler Add-on
> 2) Disable the GPU process again (set layers.gpu-process.enabled to false)
> 3) Disable Extended Telemetry (set toolkit.telemetry.enabled to false)
> 
> Restart the browser, and repeat your experiment. Does the performance
> improve? If so, this would strengthen the thread starvation hypothesis.

Did

https://perfht.ml/2f9lZTe

with 1,2,3 disabled and also with sandbox set to 1(was sset to 1 in FF56b12 so tested it)

(In reply to Mike Conley (:mconley) (:⚙️) from comment #181)
> Also, out of curiosity, you haven't accidentally set layers.d3d11.force-warp
> to true at any point, have you?

No always try to use new profile and did not find the pref
maybe you meant this?
webgl.angle.force-warp;false


Happens of other laptops(new graphics too in FF57 only)
setting sandbox from 4 to 1 has a slightly less cpu usage(2%-5%)

Comment 183

[u595893]

Attachment: settings.js

Tested on a 4GB(newer graphics) & 2GB laptops

Comment 184

[u595893]

Disabling those did not improve the performance comment 180 ,
attached the setting so you can look into the settings and details of the profile or any other settings.
Ty

Comment 185

[u595893]

https://crash-stats.mozilla.com/report/index/22d57865-38ae-4479-b4eb-e04a90170920

if you need it just in case.

Comment 186

[Jared Wein [:jaws] (please needinfo? me)]

I'm going to properly assign this to mconley since he's been doing most of the legwork here. I'll stand by and write any patches necessary if we can figure this out more. It seems that this may be a lower level platform issue that was exposed by the SVG loading indicators.

Comment 187

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8905710 [details]
Bug 1397092 - Switch to an APNG loading indicator when the browser is under schedule pressure.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/177508/diff/2-3/

Comment 188

[Dão Gottwald [:dao]]

Comment on attachment 8905710 [details]
Bug 1397092 - Switch to an APNG loading indicator when the browser is under schedule pressure.

https://reviewboard.mozilla.org/r/177508/#review187714

::: browser/base/content/tabbrowser.css:23
(Diff revision 3)
>  .tabbrowser-tabs[closebuttons="activetab"] > .tabbrowser-tab > .tab-stack > .tab-content > .tab-close-button:not([selected="true"]),
>  .tab-icon-image:not([src]):not([pinned]):not([crashed])[selected],
>  .tab-icon-image:not([src]):not([pinned]):not([crashed]):not([sharing]),
>  .tab-icon-image[busy],
>  .tab-throbber:not([busy]),
> +.tab-throbber-fallback:not([busy]),

drive-by feedback: there's another reference to .tab-throbber in browser/base/content/browser.css that you probably want to update

::: browser/themes/shared/tabs.inc.css:316
(Diff revision 3)
> +
> +.tab-throbber-fallback[progress] {
> +  list-style-image: url("chrome://browser/skin/tabbrowser/tab-loading.png");
> +}
> +
> +#TabsToolbar[brighttext] .tabbrowser-tab:not([visuallyselected=true]) .tab-throbber-fallback[progress] {

#TabsToolbar[brighttext] .tab-throbber-fallback[progress]:not([selected=true]) {

Comment 189

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8905710 [details]
Bug 1397092 - Switch to an APNG loading indicator when the browser is under schedule pressure.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/177508/diff/3-4/

Comment 190

[Jared Wein [:jaws] (please needinfo? me)]

Thanks for the drive-by feedback!

I pushed my latest patch to tryserver,
https://treeherder.mozilla.org/#/jobs?repo=try&revision=42ecae6d4ffa671fb1560849dbaa16683c82213b

shellye, can you download a build from there and test it out? Note that this is controlled by the `browser.schedulePressure.timeoutMs` preference in about:config. By default it is set to 1000 right now (1 second). The actual number is double the preference value.

So to trigger this by default, we would have to have a 1 second period of busy-ness by the browser after waiting 1 second (I used the value twice).

Comment 191

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8905710 [details]
Bug 1397092 - Switch to an APNG loading indicator when the browser is under schedule pressure.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/177508/diff/4-5/

Comment 192

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8905710 [details]
Bug 1397092 - Switch to an APNG loading indicator when the browser is under schedule pressure.

https://reviewboard.mozilla.org/r/177508/#review188932

I like the idea here, and my comments are mostly cosmetic. I'm hesitant to add this added layer though without confirmation from someone (hopefully shellye) that this actually works in improving their experience.

::: browser/base/content/tabbrowser.xml:773
(Diff revision 5)
> +                        if (!document.querySelector(".tabbrowser-tab[busy]")) {
> +                          options.continueMonitoring = false;
> +                        }

Nit: I'm not a huuuuuge fan of functions that take in object arguments and manipulate them. Can we have this return the options instead?

::: browser/modules/SchedulePressure.jsm:20
(Diff revision 5)
> +
> +this.SchedulePressure = {
> +  _idleCallbackWeakMap: new WeakMap(),
> +  _setTimeoutWeakMap: new WeakMap(),
> +
> +  startMonitoring(window, {highPressureFn, lowPressureFn}) {

Can you please add documentation to these functions, and to the top of the SchedulePressure object describing its purpose and use?

::: browser/modules/SchedulePressure.jsm:48
(Diff revision 5)
> +      this._setTimeoutWeakMap.set(window, window.setTimeout(() => {
> +        if (window.closed) {
> +          return;
> +        }
> +        let nextCallbackId = window.requestIdleCallback(callbackFn, {timeout: TIMEOUT_AMOUNT});
> +        this._idleCallbackWeakMap.set(window, nextCallbackId);
> +      }, TIMEOUT_AMOUNT));
> +    };
> +
> +    this._setTimeoutWeakMap.set(window, window.setTimeout(() => {
> +      if (window.closed) {
> +        return;
> +      }
> +      let callbackId = window.requestIdleCallback(callbackFn, {timeout: TIMEOUT_AMOUNT});
> +      this._idleCallbackWeakMap.set(window, callbackId);
> +    }, TIMEOUT_AMOUNT));

Nit: This feels like it could be abstracted out to its own function.

Comment 193

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8905710 [details]
Bug 1397092 - Switch to an APNG loading indicator when the browser is under schedule pressure.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/177508/diff/5-6/

Comment 194

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8905710 [details]
Bug 1397092 - Switch to an APNG loading indicator when the browser is under schedule pressure.

https://reviewboard.mozilla.org/r/177508/#review189310

Looking pretty good! See below.

::: browser/base/content/tabbrowser.xml:782
(Diff revision 6)
> +                        // stop monitoring schedule pressure. We don't stop monitoring
> +                        // during high pressure times because we want to eventually
> +                        // return to the SVG tab loading animations.
> +                        if (!document.querySelector(".tabbrowser-tab[busy]")) {
> +                          SchedulePressure.stopMonitoring(window);
> +                          return {continueMonitoring: false};

I think ESLint is going to yell at you for only sometimes returning a value, no?

::: browser/modules/SchedulePressure.jsm:28
(Diff revision 6)
> +  _idleCallbackWeakMap: new WeakMap(),
> +  _setTimeoutWeakMap: new WeakMap(),
> +  _telemetryCallbackWeakMap: new WeakMap(),
> +
> +  _createTimeoutFn(window, callbackFn) {
> +    return function() {

You might want to return an arrow function here instead. I'm getting lots of these errors when I run this:

```
JavaScript error: resource:///modules/SchedulePressure.jsm, line 35: TypeError: this._idleCallbackWeakMap is undefined
```

::: browser/modules/SchedulePressure.jsm:40
(Diff revision 6)
> +      this._idleCallbackWeakMap.set(window, nextCallbackId);
> +
> +      // Don't create another timeout-less idle callback if the first
> +      // one hasn't completed yet.
> +      if (!this._telemetryCallbackWeakMap.has(window)) {
> +        TelemetryStopwatch.start("FX_PAGE_LOAD_IDLE_MS", window);

FX_PAGE_LOAD_IDLE_MS sounds maybe a bit too coupled to the page load throbbers, and this module seems generic enough that maybe we want to call this, like,

FX_SCHEDULE_PRESSURE_IDLE_SAMPLE_MS or something.

::: browser/modules/SchedulePressure.jsm:62
(Diff revision 6)
> +   * @param  window
> +   *         The DOM window of the requestee.
> +   * @param  options
> +   *           highPressureFn
> +   *           A function that will be called when the idle callback
> +   *           fails to called within the time specified by TIMEOUT_AMOUNT.

Nit: "fails to be called"

::: toolkit/components/telemetry/Histograms.json:6117
(Diff revision 6)
> +  "FX_PAGE_LOAD_IDLE_MS": {
> +    "record_in_processes": ["main"],
> +    "expires_in_version": "default",
> +    "kind": "exponential",
> +    "high": 10000,
> +    "n_buckets": 20,
> +    "description": "Firefox: Time taken to get an idle callback while loading a page (ms). Loading of about: pages is not counted."
> +  },

Just a heads up that you'll need data review here, and I can't give that.

::: toolkit/components/telemetry/Histograms.json:6119
(Diff revision 6)
>      "n_buckets": 20,
>      "description": "Firefox: Time taken to load a page (ms). This includes all static contents, no dynamic content. Loading of about: pages is not counted."
>    },
> +  "FX_PAGE_LOAD_IDLE_MS": {
> +    "record_in_processes": ["main"],
> +    "expires_in_version": "default",

Can't do this anymore - it wants a real version number.

::: toolkit/components/telemetry/Histograms.json:6123
(Diff revision 6)
> +    "record_in_processes": ["main"],
> +    "expires_in_version": "default",
> +    "kind": "exponential",
> +    "high": 10000,
> +    "n_buckets": 20,
> +    "description": "Firefox: Time taken to get an idle callback while loading a page (ms). Loading of about: pages is not counted."

Apparently, this needs alert_emails and bug_numbers set.

Comment 195

[Mike Conley (:mconley) (:⚙️)]

Hey shellye,

It's possible that jaws' patch in bug 1398600 will help with this. Can you test it? He's posted a link to a build in that bug, and needinfo'd you.

Comment 196

[Mike Conley (:mconley) (:⚙️)]

Whoops, I got things backwards - _this_ is the bug with the patches.

When this patch starts to settle, hopefully shellye will be available to test it.

Comment 197

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8905710 [details]
Bug 1397092 - Switch to an APNG loading indicator when the browser is under schedule pressure.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/177508/diff/6-7/

Comment 198

[Justin Dolske [:Dolske]]

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #192)

> I like the idea here, and my comments are mostly cosmetic. I'm hesitant to
> add this added layer though without confirmation from someone (hopefully
> shellye) that this actually works in improving their experience.

This bug is getting long -- is comment 164 still what we think is happening here?

I have a few questions...

Do we have any data to to help guide an understanding of how common a problem this is?

Do we understand why a 20fps APNG would perform noticeably better than a 30fps SVG (from comment 71)?

Is there a better / longer term solution to this problem?

I'm also very reluctant to be adding an extra fallback path (and all the risk of having various types of regressions resulting from having a seldom-used codepath).

Comment 199

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

If 20FPS APNG animation perform noticeably better than 30FPS SVG animation,
Firefox should use faster code.

+ droping ni, as question was already answered

Comment 200

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Justin Dolske [:Dolske] from comment #198)
> Do we understand why a 20fps APNG would perform noticeably better than a
> 30fps SVG (from comment 71)?

@jmuizelaar, are you able to answer this? Is the rendered SVG shared across each instance? Is a CSS animation that only performs a translation of the SVG significantly more expensive then advancing to the next frame of an APNG? I imagine the extra layers and clipping of the SVG translation here doesn't help.

Comment 201

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

One more thing to add as this could be related, regression range is different, but it's worth to mention, that in bug #1283302, "nglayout.initialpaint.delay" was changed from 250ms to 5ms, which resulted in some performance related regressions like bug #1385479 and bug #1332558. So maybe this bad SVG performance is due to that change.

Comment 202

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracking this as a 57 blocker.

Comment 203

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #200)
> (In reply to Justin Dolske [:Dolske] from comment #198)
> > Do we understand why a 20fps APNG would perform noticeably better than a
> > 30fps SVG (from comment 71)?
> 
> @jmuizelaar, are you able to answer this? Is the rendered SVG shared across
> each instance? Is a CSS animation that only performs a translation of the
> SVG significantly more expensive then advancing to the next frame of an
> APNG? I imagine the extra layers and clipping of the SVG translation here
> doesn't help.

Maybe jwatt can help?

Comment 204

[Jonathan Watt [:jwatt]]

Yikes! 200 comments! A summary in the User Story field might be helpful to people coming fresh to this bug. :) For now I've had to skim read.

So from what I understand, this SVG icon is causing problems:

https://dxr.mozilla.org/mozilla-central/rev/97efdde466f18cf580fda9673cf4c38ee21fc7b7/browser/themes/shared/tabbrowser/loading.svg

That looks to have 60 frames worth of path data encoded into a single SVG <path> element. The SVG and embedding element are 60x wider than the actual displayed size of the image, and what we do is we clip the embedding element to the displayed image width and animate a CSS transform translateX to effectively show "60 fps":

https://dxr.mozilla.org/mozilla-central/rev/97efdde466f18cf580fda9673cf4c38ee21fc7b7/browser/themes/shared/tabs.inc.css#159

What I *think* is the expected behavior here is that we render this very wide SVG, cache the rendering in imagelib, and uploaded the cached rendering to the GPU for clipping and display. The upload should only happens once per tab (i.e. not repeatedly for each frame - that would be a huge bug), but if you're loading 10 tabs at once then 10 instances of the rendering will still all be uploaded to the GPU around the same time. Once uploaded to the GPU, the image has to be translated and clipped every frame. I'm not sure how expensive that is, but I wouldn't be surprised if that's what's causing the issues here. Hopefully Jeff or someone from the gfx team can provide more information from here.

I'm not familiar with the APNG codepaths in imagelib, but I imagine we upload 1 frame (16 CSS px wide, not 960 CSS px wide as for the SVG) to the GPU every time we need it, and without requiring any work on the GPU to do translation or clipping.

Comment 205

[Jeff Muizelaar [:jrmuizel]]

I haven't read all of the comments but do we have any evidence to suggest that performance difference isn't completely explained by the frame rate change?

Comment 206

[Mike Conley (:mconley) (:⚙️)]

According to comment 80, the 30fps SVG performed worse than both the APNG and the original throbber in Firefox 55.

I suppose it's not possible to somehow tell the compositor thread that the texture that we're uploading for one tab is the same as for the others, so that it can do its own duplication without requiring us to upload 1 960px wide rasterized SVG per tab?

Comment 207

[Mike Conley (:mconley) (:⚙️)]

Hey Virtual_Man - am I correct when I recall you writing somewhere (in this massive bug, or maybe elsewhere) that you experience this issue as well? If so, does the build in comment 190 help you?

Comment 208

[Jeff Muizelaar [:jrmuizel]]

I bought a Lenovo B50-45 which has the same CPU/GPU as the original reporter. I receive it on Friday.

Comment 209

[Jonathan Watt [:jwatt]]

Attachment: Bug 1397092, part 1 - Document and do some renaming for SVGObserverUtils' SourceReference.

Review commit: https://reviewboard.mozilla.org/r/186200/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/186200/

Comment 210

[Jonathan Watt [:jwatt]]

Attachment: Bug 1397092, part 2 - Document and do some renaming for SVGUseElement's SourceReference.

Review commit: https://reviewboard.mozilla.org/r/186202/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/186202/

Comment 211

[Jonathan Watt [:jwatt]]

Attachment: Bug 1397092, part 3 - Document and do some renaming for SVGMPathElement's PathReference.

Review commit: https://reviewboard.mozilla.org/r/186204/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/186204/

Comment 212

[Jonathan Watt [:jwatt]]

Attachment: Bug 1397092, part 4 - Document and do some renaming for SVGAnimationElement's TargetReference.

Review commit: https://reviewboard.mozilla.org/r/186206/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/186206/

Comment 213

[Jonathan Watt [:jwatt]]

Attachment: Bug 1397092, part 5 - Document and do some renaming for nsSMILTimeValueSpec's TimeReferenceElement.

Review commit: https://reviewboard.mozilla.org/r/186208/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/186208/

Comment 214

[Jonathan Watt [:jwatt]]

Comment on attachment 8914949 [details]
Bug 1397092, part 1 - Document and do some renaming for SVGObserverUtils' SourceReference.

Argh, sorry, wrong bug number.

Comment 215

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #207)
> Hey Virtual_Man - am I correct when I recall you writing somewhere (in this
> massive bug, or maybe elsewhere) that you experience this issue as well? If
> so, does the build in comment 190 help you?

Unfortunately, I won't be having access to that netbook where I could reproduce this issue for over 1 month, so I suspect that OP will reply results faster.

Comment 216

[Mike Conley (:mconley) (:⚙️)]

Duping this over to a new bug (bug 1406414), since this one has gotten super long and unwieldy. I'm collecting all of the salient data there.

Comment 217

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Removing the tracking flag from here and moving it to the other new bug.

Comment 218

[u595893]

Sorry for the late reply guys

Can you guys try few experiments?

Double the bookmarks and add more heavy pages,

limit ram to 2gb or less so cpu has more work to do.

Now measure?

There will be a significant delay compared to FF55/56 with pages loading completely
and rendering speeding up when a few pages complete loading or are stopped.

16px vs 900px no wonder the performance is poor,
can the throbbers be OOMT with lowest priority?

install amd drivers and with amd utility in clock speeds on battery set max battery life,
there is even more performance drop.

Install adblocker and see the performance hit.

Mike & Jaws do the testing is still required?
In the other bug you mentioned the Excess CPU use and can reproduce the problem so what's next.

Comment 219

[u595893]

Mike why does disabling e10s improve the overall performance of FF57?
say compared to with ipc process =1

Comment 220

[u595893]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #190)
> Thanks for the drive-by feedback!
> 
> I pushed my latest patch to tryserver,
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=42ecae6d4ffa671fb1560849dbaa16683c82213b
> 
> shellye, can you download a build from there and test it out? Note that this
> is controlled by the `browser.schedulePressure.timeoutMs` preference in
> about:config. By default it is set to 1000 right now (1 second). The actual
> number is double the preference value.
> 
> So to trigger this by default, we would have to have a 1 second period of
> busy-ness by the browser after waiting 1 second (I used the value twice).

Wanted to test this but how to download?
Not finding any zips or links for download.
Can you help.

Comment 221

[Jared Wein [:jaws] (please needinfo? me)]

Win32: https://queue.taskcluster.net/v1/task/Eu1Ni_bzT6-0RTBKRTKGZQ/runs/0/artifacts/public/build/target.zip
Win64: https://queue.taskcluster.net/v1/task/WXPS-VFDRYqSTknKbgOLcg/runs/0/artifacts/public/build/target.zip

Comment 222

[u595893]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #221)
> Win32:
> https://queue.taskcluster.net/v1/task/Eu1Ni_bzT6-0RTBKRTKGZQ/runs/0/
> artifacts/public/build/target.zip
> Win64:
> https://queue.taskcluster.net/v1/task/WXPS-VFDRYqSTknKbgOLcg/runs/0/
> artifacts/public/build/target.zip

Thanks


These builds indeed have far better performance than SVG ones.
When will these be merged?

Can the controlling pref be also attached to cosmetic animations?
So can easily be disabled?

Comment 223

[u595893]

The APNG indicators are so smooth compared to SVG one's,
SVG makes it fell like the browser is running in slow motion.

Comment 224

[timbugzilla]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #221)
> Win32:
> https://queue.taskcluster.net/v1/task/Eu1Ni_bzT6-0RTBKRTKGZQ/runs/0/
> artifacts/public/build/target.zip
> Win64:
> https://queue.taskcluster.net/v1/task/WXPS-VFDRYqSTknKbgOLcg/runs/0/
> artifacts/public/build/target.zip

These builds seem to fix Bug 1407462 (Janky close tab animation with Touch Density UI) too.

Comment 225

[u595893]

yup tested on 2 different machines(both showed this problem)

Now the CPU usage is a tad higher only compared to old indicators
and 30-40% less than SVG indicators.

Can this be uplifted to beta 57?
with controlled by permanently by toolkit.cosmeticAnimations.enabled=false
not just pressure as on the hardware know svg creates a havoc so no use wasting CPU looking for it just disabling it completely and falling back to APNG)

Comment 226

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8905710 [details]
Bug 1397092 - Switch to an APNG loading indicator when the browser is under schedule pressure.

https://reviewboard.mozilla.org/r/177508/#review191196

Sounds like this patch might be what we need then - it seems to address shellye's issue, anyhow.

I don't think this is at all likely to make 57, but we can try it for 58. Jared, would you still be willing to pick this up? If so, can you re-push the patch to bug 1406414 ?

Comment 227

[u595893]

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos from comment #226)

>it seems to address
> shellye's issue, anyhow.
> 

No it just improves the situation compared to SVG one's

FF56b12 still has the better performance by a long way.

Comment 228

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos from comment #226)
> I don't think this is at all likely to make 57, but we can try it for 58.
> Jared, would you still be willing to pick this up? If so, can you re-push
> the patch to bug 1406414 ?

Yep, done.

Comment 229

[u595893]

@jaws is there any way to know what % of firefox user base is hitting the fallback animation? bug 1406414
and how it impacts the page loading times?
and why does SVG have such a bad perf even in pdf.js with lots of SVG?

@mike any major fix?

Comment 230

[Jared Wein [:jaws] (please needinfo? me)]

Please don't comment with the same questions in multiple bugs. I commented at https://bugzilla.mozilla.org/show_bug.cgi?id=1406414#c28 with a summary of the situation. We will not have enough data for our telemetry probe until a few weeks after the Firefox 57 release at the earliest.

Comment 231

[u595893]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #230)
> Please don't comment with the same questions in multiple bugs. I commented
> at https://bugzilla.mozilla.org/show_bug.cgi?id=1406414#c28 with a summary
> of the situation. We will not have enough data for our telemetry probe until
> a few weeks after the Firefox 57 release at the earliest.

Oh ok but this has not been uplifted to firefox57 right?
So regular telemetry  you men right?
But not the new specific one of APNG fallback telemetry on what % of user base is hitting it?.

Also regarding the priority of process , tried with mike but it has no positive effect
so the main issue is still not fixed and this is just a band-aid

Comment 232

[u595893]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #230)
> Please don't comment with the same questions in multiple bugs. I commented
> at https://bugzilla.mozilla.org/show_bug.cgi?id=1406414#c28 with a summary
> of the situation. We will not have enough data for our telemetry probe until
> a few weeks after the Firefox 57 release at the earliest.

Do the telemetry show the problem yet?

Comment 233

[Jared Wein [:jaws] (please needinfo? me)]

I responded to comment 232 with https://bugzilla.mozilla.org/show_bug.cgi?id=1406414#c41. Please don't ask the same question in multiple bugs :)

Comment 234

[Rana Raju]

[redacted - mhoye]