1837482 - mozilla::ContentEventHandler::GetTextLength takes lots of time in sp3 TipTap

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

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

See the profiles, mozilla::ContentEventHandler::GetTextLength takes a lot of time.
https://speedometer-preview.netlify.app/?developerMode=&suites=Editor-TipTap

https://profiler.firefox.com/public/x8w23gh6z0ww7hx4g4e09d36f3s7zvgqrjnwct0/flame-graph/?globalTrackOrder=0wa&hiddenGlobalTracks=0w57wa&hiddenLocalTracksByPid=20212-0w2~6388-0wze~14996-0wxq~13740-0w7~27596-0wx5~21144-0wx5~3500-0wx3~24208-0wf~11600-0wr~18848-0wr~24780-0wr&profileName=Firefox%20Editor-TipTap-BrowserWin-Jun8&symbolServer=http%3A%2F%2F127.0.0.1%3A3000%2F2myjwndvyn9v5ah43r9cx58xpni8yhqrswbh57j&thread=E7&transforms=fs-m--sync%2C-async~df-1996~df-7217~df-1995~df-7414~df-9913~df-1893~df-6043~df-4730~df-14838~df-4032~df-4790~df-16328~df-17392~df-16087~df-6629~df-6854~df-5257~df-7352~df-7409~df-7316~df-7315~df-18485~df-6899~df-3399~df-3418~df-2442~df-3709~df-3728~df-11478~df-6975~df-19481~df-6843~df-8243~ff-5989&v=9

https://profiler.firefox.com/public/x8w23gh6z0ww7hx4g4e09d36f3s7zvgqrjnwct0/flame-graph/?globalTrackOrder=0wa&hiddenGlobalTracks=0w57wa&hiddenLocalTracksByPid=20212-0w2~6388-0wze~14996-0wxq~13740-0w7~27596-0wx5~21144-0wx5~3500-0wx3~24208-0wf~11600-0wr~18848-0wr~24780-0wr&profileName=Firefox%20Editor-TipTap-BrowserWin-Jun8&symbolServer=http%3A%2F%2F127.0.0.1%3A3000%2F2myjwndvyn9v5ah43r9cx58xpni8yhqrswbh57j&thread=E7&transforms=fs-m--sync%2C-async~df-1996~df-7217~df-1995~df-7414~df-9913~df-1893~df-6043~df-4730~df-14838~df-4032~df-4790~df-16328~df-17392~df-16087~df-6629~df-6854~df-5257~df-7352~df-7409~df-7316~df-7315~df-18485~df-6899~df-3399~df-3418~df-2442~df-3709~df-3728~df-11478~df-6975~df-19481~df-6843~ff-8243&v=9

masayuki, would you have time to take a look at this?

Comment 1

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

Note, Editor-TipTap was recently updated, so that could have revealed this issue.
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=019009b60f0a846abbd67eaf40e39cdb5d774c9a&tochange=8ca41fa1fe7f665f3fb17e1ee1ecb9dc533e3970 seems to be the regression range after all

Comment 2

[Markus Stange [:mstange]]

This is responsible for the entire performance gap to Chrome on this subtest and needs to be fixed.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

This is windows only right? It seems on macOS and Linux we don't do newline conversion shenanigans.

Comment 4

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

I believe this is Windows only.
At least on Android we're faster than release Chrome.

On Mac Nightly is slower than Chrome, but not as much as on Windows.

Comment 5

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

(Sorry, I'm still on sick leaves, hopefully I'll be able to take a look next week.)

Comment 6

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

Oh, I misunderstood. This must be a long standing issue, not a regression of bug 1835353. But anyway, I'll take a look.

Comment 7

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

It seems that mState.mIs2b check in nsTextFragment::CharAt is not optimized from the for loop in CountNewlinesInXPLength.

Comment 8

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

Attachment: Bug 1837482 - Make `CountNewlinesInXPLength` and `CountNewlinesInNativeLength` not scan `TextFragment` directly r=smaug!

TextFragment::CharAt() considers whether it's in the 2b-mode or not in each
call in theory. Let's create dependent string for skipping the redundant
checks.

Depends on D180767

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8f2cf32883cd
Make `CountNewlinesInXPLength` and `CountNewlinesInNativeLength` not scan `TextFragment` directly r=smaug

Comment 10

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/8f2cf32883cd