2041354 - Testcase creating nodes, ranges and selections is 2050x slower in Firefox. Spends all the time in nsContentUtils::AddScriptRunner / SelectionChangeEventDispatcher (STR in comment 3)

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Mayank Bansal]

Attachment: Nodes and Ranges and Selection.html

STR:

1. Open testcase
2. Click on "1. Init nodes" --> fast
3. Click on "2a. Bind N ranges" -->fast
4. Click on "2b. Bind ranges to selection" -->fast
5. Click on "Insert M front" --> Slow
   Measure the time for the 5th step

Firefox Samply: https://share.firefox.dev/49gg7mC (205s)
Firefox gecko profiler (Partial): https://share.firefox.dev/4uzMFAz
Chrome: https://share.firefox.dev/4dpQv9i (100ms?)

This kinda looks bad. :masayuki, what do you think?

Comment 1

[Mayank Bansal]

needinfo for comment #0

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

The test is using selection.addRange(activeRanges[i]);. Other browsers support only 1 range per selection currently.
But currently, isn't the test basically testing behavior which other browsers don't support, so of course they are way faster?

(but that is may change soon https://github.com/w3c/selection-api/issues/358 )

Comment 3

[Mayank Bansal]

Attachment: Nodes and 1Range and selection.html

Nodes=100000, Insertions= 20000
Chrome: https://share.firefox.dev/3Rqgvsz (19s) - Insert M end + Delete M end
Firefox: https://share.firefox.dev/4tRvbhZ (150s) - insert M end + Delete M front

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

It seems that SelectionChangeEventDispatcher::OnSelectionChange() should enqueue its job and dispatch selectionchange event once unless we need to dispatch selectionchange per mutation if each one changes the range.

Currently, the spec defines that as dispatched every mutation, but I'm not sure whether the other browsers behave so. From web app's point of view, only one selectionchange event should be reasonable.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oh, the spec was changed in https://github.com/w3c/selection-api/pull/172 to schedule only one selectionchange event. So, we should be able to improve the performance.