Performance degradation in Chrome 80 with some Windows devices

[korria]

Just updated to Chrome 80. Anybody notice performance issues in Chrome 80? Tiles seem to take a very long time to load compared to what it used to do. Animating tilesets also are not smooth any more. I've tested multiple versions of mapbox from 1.6.0 through 1.8.1. I have Chrome Version 80.0.3987.132

[mourner]

@korria can you tell more about your machine / GPU / OS? A dual-GPU Macbook Pro perhaps? Is this degradation only noticeable on your machine or did you try any others?

[doylemark]

absolutely terrible performance here on Windows, shockingly bad. GTX1060 6GB card with 5.0Ghz processor, works fine on mac/firefox/safari

Here's a comparison between chrome (left) and firefox (right). Seems to be lagging the entire browser.. Both pages refreshed at the same time

[mourner]

That's really weird! We haven't seen any other similar reports. Any other details you could provide? Maybe try running the performance recording in Chrome DevTools and see if anything stands out, and share the trace if so?

[doylemark]

I recorded a loading of the map which took over 45 seconds in dev tools, here's the profile Profile-20200314T001648.zip

[asheemmamoowala]

There is something very odd about that profile. @korria @doyle-mark are these results consistently reproducing on your device(s)? If so, could you please share more information on those devices and whether other web pages/sites are working without issue.

What stands out from the profile shared is that the slowdown is across all operations, and not isolated to CPU/GPU/network.

• Style and sprite resources took 4-6 seconds to resolve the network requests.
• Worker source took 4+ seconds
• Many simple methods took a very long time to run
• WebWorkers took 12+ seconds to process a tile

To me this would indicate something outside of the GL-JS library - either in Chrome or on the device. I am running the same version of Chrome as the OP (80.0.3987.132) on a MacBook and do not see any changes in performance.

[doylemark]

Tested on my MacBook just now and I have perfect performance, trying to investigate further on windows to see what the issue is but have not had much luck, will report back with any findings.

results are reproducible consistently, tried all the tricks (restart, flush cache etc.)

[doylemark]

What more info can I provide on this? This is a major issue for me :)

[arindam1993]

Hey @doyle-mark , I just tried on a windows machine as well, similar desktop setup to yours, and I can't reproduce your issue. Interestingly it seems like JS execution is what seems to be effected, and not GPU performance.

Are you seeing this degradation only on GL-JS, or are other computationally heavy JS apps showing a degradation as well? You could try this https://threejs.org/examples/webgl_animation_cloth.html example.

Though highly unlikely it could also be something specific to your style, are you seeing the degradation with mapbox streets or satellite styles as well?

[doylemark]

hey, I tried changing the style and it didn't change anything. The JS execution returns to normal as soon as I remove the map from the site. Tried several other JS apps with computationally expensive Web GL demos and such and they performed perfectly. I honestly have no idea at this point, going to just keep testing different combinations. This is the repo I've been experiencing the problem if it helps to identify the issue on your end (https://github.com/doyle-mark/vatsim-map)

[asheemmamoowala]

@doyle-mark can you use https://mapbox.github.io/mapbox-gl-supported/diagnostics.html to share the diagnostics from the affected machines?

[doylemark]

Appreciate your help very much with this problem, here is my windows machine which is experiencing the problem.

One other thing I have noticed is that if I remove all the layers I have added, the performance could be described as acceptable, it's still a bit "laggy" but much better then with layers added. Seems to get exponentially worse with each layer added. I could understand but on my Macbook and on firefox I'm experiencing perfect performance with all layers added to my map.

Here is the diag info

WebGL Support: yes (webgl)
Version: WebGL 1.0 (OpenGL ES 2.0 Chromium)
Vendor: WebKit
Renderer: WebKit WebGL
Shading Language: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium)
Max Texture Size: 16384
Subpixel bits: 4
Red bits: 8
Green bits: 8
Blue bits: 8
Alpha bits: 8
Depth bits: 24
Stencil bits: 8
Max Vertex Attribs: 16
Max Vertex Uniforms: 4095
Max Varyings: 30
Max Combined Textures: 32
Max Vertex Textures: 16
Max Textures: 16
Max Fragment Uniforms: 1024
Max Cube Map Size: 16384
Max Renderbuffer Size: 16384
Max Viewport Dims: 32767 x 32767
renderbuffer_depth: 16

OES_texture_float: true
OES_texture_half_float: true
WEBGL_EXT_lose_context: false
OES_standard_derivatives: true
OES_vertex_array_object: true
WEBGL_debug_renderer_info: true
WEBGL_debug_shaders: true

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Browser vendor: Google Inc.
Browser version: 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Browser language: en-GB
Available resolution: 3440 x 1400
Screen resolution: 3440 x 1440
Color depth: 24
Pixel depth: 24

Unmasked vendor: Google Inc.
Unmasked renderer: ANGLE (NVIDIA GeForce GTX 1060 6GB Direct3D11 vs_5_0 ps_5_0)

[arindam1993]

Nothing from that stands out :( My only guess would be there's something off with how your local instance of chrome is managing WebWorkers.

Could you try with Chrome Canary or the open source Chromium build and see if it changes anything?

If that doesnt change anything could you please try using chrome://tracing, record a trace with the Javascript and Rendering preset and post it here?

Another hunch I have is this could be a sideeffect of https://github.com/mapbox/mapbox-gl-js/pull/8633 rearing again, that was introduced in 1.3.0, could you try 1.2.0 and see if that helps?

[doylemark]

Hello, I have spent many hours investigating now, and I think I have identified the problem. The issue seems to be with using the .setData() method on a source.

I have worked around this issue now by slowing down the updating of data on chrome (🎉). For comparison, FireFox can handle updating of a source with up to 1000 features every 100MS whereas Chrome is completely unusable at 300MS.

[asheemmamoowala]

@doyle-mark Can you provide a reproducible case of the problem. Using GeoJSONSource#setData()for frequent updates is expected to work in Chrome.