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)
Tracking
()
People
(Reporter: mayankleoboy1, Unassigned)
References
()
Details
Attachments
(3 files)
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.
Reporter | ||
Comment 1•19 days ago
|
||
Reporter | ||
Comment 2•19 days ago
|
||
Comment 3•19 days ago
|
||
It takes a lot in the validation of given 2 RawRangeBoundary
s... It's a guard from callers' bugs, so, in the usual cases, it just wastes the resource.
Comment 4•19 days ago
|
||
Patch 3 in Bug 1942080 introduces a ContentIterator::Init()
method which expects the range boundaries to be sorted (so, it MOZ_ASSERT
s 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)
).
Comment 5•14 days ago
•
|
||
So, we should make these checks run only in debug builds:
- https://searchfox.org/mozilla-central/rev/c5432a86ece2ce8671e7aefbe43fed9a10151227/dom/base/ContentIterator.cpp#229-232
- https://searchfox.org/mozilla-central/rev/c5432a86ece2ce8671e7aefbe43fed9a10151227/dom/base/ContentIterator.cpp#244-246
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.
- https://searchfox.org/mozilla-central/rev/d5f93d53d7d005bd303925bc166163f158142cfd/dom/base/ContentIterator.cpp#30-31,45-46,52-53
- https://searchfox.org/mozilla-central/rev/d5f93d53d7d005bd303925bc166163f158142cfd/dom/base/ContentIterator.cpp#61-62,72-73,79-80
- https://searchfox.org/mozilla-central/rev/d5f93d53d7d005bd303925bc166163f158142cfd/dom/base/ContentIterator.cpp#92-94,118-119,122
- https://searchfox.org/mozilla-central/rev/d5f93d53d7d005bd303925bc166163f158142cfd/dom/base/ContentIterator.cpp#443,467-470,489-492,510-513
- https://searchfox.org/mozilla-central/rev/d5f93d53d7d005bd303925bc166163f158142cfd/dom/base/ContentIterator.cpp#368-369,405-406,433-434
- https://searchfox.org/mozilla-central/rev/d5f93d53d7d005bd303925bc166163f158142cfd/dom/base/ContentIterator.cpp#997,1005-1006
- https://searchfox.org/mozilla-central/rev/d5f93d53d7d005bd303925bc166163f158142cfd/dom/base/ContentIterator.cpp#1109,1118-1119
- https://searchfox.org/mozilla-central/rev/d5f93d53d7d005bd303925bc166163f158142cfd/dom/base/ContentIterator.cpp#1215,1226-1227,1254-1255
(I'll be back to my current primary work after requesting review for bug 1945711)
Comment 6•14 days ago
•
|
||
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.
Comment 7•14 days ago
|
||
(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?
Comment 8•14 days ago
|
||
Good idea, thanks!
Reporter | ||
Comment 9•8 days ago
|
||
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.
Description
•