1809058 - Codepen demo (https://codepen.io/toshiya-marukubo/pen/podvabY) is slower in Nightly compared with Chrome

Status: NEW

(Core :: JavaScript Engine, task, P2)

Description

[Mayank Bansal]

Go to https://codepen.io/toshiya-marukubo/pen/podvabY
Move your mouse inside the demo pane
The shapes/circles will move

https://share.firefox.dev/3VVwqMf

Chrome is visually much more smooth

Comment 1

[Jan de Mooij [:jandem]]

This performs well for me on Mac, but in your profile I see a ton of jemalloc lock contention in the flame graph. Can you get a profile with all background threads enabled in the profiler settings? Maybe that will tell us which thread we're waiting for...

Comment 2

[Mayank Bansal]

https://share.firefox.dev/3WWEsFR

Comment 3

[Mayank Bansal]

Attachment: about:support

Comment 4

[Jan de Mooij [:jandem]]

(In reply to Mayank Bansal from comment #2)

https://share.firefox.dev/3WWEsFR

Thanks! This shows a lot of the jemalloc lock contention on the main thread is caused by the GC freeing memory on helper threads. In particular, there's a lot of time under VirtualFree. Jon suggested we're holding the jemalloc lock at this point. It would be nice if we could unlock before releasing the memory to the OS.

Comment 5

[Paul Bone [:pbone]]

This confirms some suspicions.

I had seen a profile where jemalloc's free() code was MUCH slower than Linux's builtin allocator. But I didn't realise it held the lock during a system call. These profiles are great, thank you!

Comment 6

[Mayank Bansal]

Latest Profile: https://share.firefox.dev/3kU2xzb