1768359 - Scrolling through TurnitIn marking page spikes CPU to 20% and is incredibly slow

Status: NEW

(Core :: Graphics: Canvas2D, defect, P2)

Description

[gerard.carroll]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

Navigated to the TurnitIn marking portal and opened an assignment.
The assignments are PDFs, or scanned images.

I realise this is not much information, and TurnitIn probably isn't accessible, so if I can give more information please tell me how.

Actual results:

Tried to scroll down and it was very laggy and slow. CPU usage spiked up towards 20%.

Expected results:

Should have been smooth, with low CPU usage

Comment 1

[gerard.carroll]

I just tried on a new profile, and while scrolling saw CPU usage hit 54%.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[gerard.carroll]

Profiler data: https://share.firefox.dev/39MeNfp

Comment 4

[Markus Stange [:mstange]]

Is performance better in other browsers? It looks like it's just a really slow page - they have a 40ms MozMousePixelScroll handler. There's also some slow canvas 2d drawing, which is Firefox's fault, but that's not where most of the jank is coming from.

Comment 5

[gerard.carroll]

I just tried in Edge. It definitely is a costly site, CPU spikes up to 30%ish, but the scrolling experience is still smooth.

Comment 6

[Markus Stange [:mstange]]

Could you record a profile in Edge using their performance devtools, save it as a file, import it into profiler.firefox.com, upload it, and then share it here?

Comment 7

[gerard.carroll]

Sorry for the slow update:
https://share.firefox.dev/3yLTIMz

Comment 8

[Markus Stange [:mstange]]

Looks like they only spend 12ms in the wheel event handler: https://share.firefox.dev/3MRD16p , so that's almost 4x as fast.
(The EventDispatch markers are all for wheel events, you can tell by right-clicking and copying the marker JSON.)

Comment 9

[Bas Schouten (:bas.schouten)]

This appears to be yet another example of slow megamorphic JS based on the profile.

The Performance Priority Calculator has determined this bug's performance priority to be P3. If you'd like to request re-triage, you can reset the Performance flag to "?" or needinfo the triage sheriff.

Platforms: Windows
Impact on site: Causes noticeable jank
Websites affected: Rare
[x] Causes severe resource usage

Comment 10

[Nicolas B. Pierron [:nbp]]

Jan, this sounds like a job for WatchTower?

Comment 11

[Jan de Mooij [:jandem]]

For the profile in comment 3, if I look at the flame graph most of the time seems to be in canvas and graphics code. That might be the lowest hanging fruit.

@Markus: it's weird that in the flame graph, on the right side, there are some DOM stacks that are marked as JS (yellow) instead of DOM (blue). For example the stack below. Any idea what's happening there? It works fine for this builtin elsewhere.

mozilla::dom::CanvasRenderingContext2D::FillText(nsTSubstring<char16_t> const&, double, double, mozilla::dom::Optional<double> const&, mozilla::ErrorResult&)
mozilla::dom::CanvasRenderingContext2D_Binding::fillText(JSContext*, JS::Handle<JSObject *>, void*, JSJitMethodCallArgs const&)
mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy,mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*)
0xeae383c8ff
js::RunScript
...

Comment 12

[Markus Stange [:mstange]]

(In reply to Jan de Mooij [:jandem] from comment #11)

For the profile in comment 3, if I look at the flame graph most of the time seems to be in canvas and graphics code. That might be the lowest hanging fruit.

You're right. I'm not sure why I said in comment 4 that most of the jank is not coming from canvas 2d drawing - the longest periods of jank are clearly spent blocking on remote canvas 2d drawing.

@Markus: it's weird that in the flame graph, on the right side, there are some DOM stacks that are marked as JS (yellow) instead of DOM (blue). For example the stack below. Any idea what's happening there?

Hmm, I think what happened there is that we didn't insert the label because the JSContext thought that the profiler wasn't running; AUTO_PROFILER_LABEL_DYNAMIC_FAST doesn't do any work unless js::GetContextProfilingStackIfEnabled(aJSContext) returns something non-null. The main thread's event loop was quite busy when the profiler was started, so it's possible that the TriggerPollJSSamplingOnMainThread runnable didn't get a chance to run for many seconds. However, we have another call to PollJSSampling which runs during the JS interrupt handler, so maybe that handler didn't run either or the functionality is broken.

Comment 13

[Jan de Mooij [:jandem]]

Moving this bug per comment 12...