Open Bug 1944760 Opened 19 days ago Updated 7 days ago

Pasting text on https://prosemirror.net/ is 10x slower in Nightly and 25x slower with 2.5x bigger text.

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, enhancement)

enhancement

Tracking

()

People

(Reporter: mayankleoboy1, Unassigned)

References

()

Details

Attachments

(3 files)

Attached file angular.js

Go to https://prosemirror.net/
Copy-paste teh attached sample files into the editor on their homepage.

angularjs (1.3mb text)
Nightly: https://share.firefox.dev/4141QG5 (8.2s)
Chrome: https://share.firefox.dev/3WHBZ46 (840ms)

sqlite.js (3.2mb)
Nightly: https://share.firefox.dev/40R3R8j (40s)
Chrome: https://share.firefox.dev/42zjuT3 (1.6s)

Feel free to dupe to existing bugs.

Attached file about:support

It takes a lot in the validation of given 2 RawRangeBoundarys... It's a guard from callers' bugs, so, in the usual cases, it just wastes the resource.

Patch 3 in Bug 1942080 introduces a ContentIterator::Init() method which expects the range boundaries to be sorted (so, it MOZ_ASSERTs the expensive ComputePoints() call). Maybe it does make sense to look at the usages of the content iterator to see if there are cases where we can guarantee that the points are in order and we don't have to perform these checks.

I also have a patch in Bug 1503581 which is currently blocked because of legacy mutation events, which could help speed up nsContentUtils::ComparePoints() greatly by caching the node indices in a DOM generation, especially in the case where this is very slow (repeatedly computing indices of siblings in a case where a node has many child nodes, which essentially makes it O(n^2)).

So, we should make these checks run only in debug builds:

And here does similar thing, but I don't know whether we can stop using nsRange here.

Additionally, there are some expensive points, but I don't know whether we can stop comparing them.

(I'll be back to my current primary work after requesting review for bug 1945711)

I have a patch in bug 1503581 which when landed would likely improve the situation further by reducing the need to call ComparePoints() by a lot.

Oh, I said that in comment 4 already. Oops.

See Also: → 1503581

(In reply to Jan Jaeschke [:jjaschke] from comment #4)

I also have a patch in Bug 1503581 which is currently blocked because of legacy mutation events

Should bug 1503581 depend on bug 769207?

Good idea, thanks!

angularjs (1.3mb text): https://share.firefox.dev/3Euoo9Y (4.7s) -> 1.7x faster than before.
sqlite.js (3.2mb text): https://share.firefox.dev/4hpoMFg (14s) -> 2.8x faster than before.

We became faster, but the gap with Chrome remains.

Wow, I did NOT optimize the comparing code in bug 1945711 but I make it put off to compute the index when it becomes necessary. So, it means that the reported case hit the worst scenario of the comparing methods.

I guess that optimizing ContentIterator would fix (or at least really improve) the gap.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: