Open Bug 1365874 Opened 3 years ago Updated 1 year ago

Selection->Collapse is slow


(Core :: DOM: Selection, defect)

55 Branch
Not set





(Reporter: m_kato, Assigned: masayuki)


(Blocks 2 open bugs)


On bug 1346723's benchmark, Selection->Collapse() spends more time.  input.value setter for focused element has to  set caret after updating value.

Actually, 6% of nsTextEditorStaet::SetValue is Selection::Collapse at least.  After fixing bug 1358025, more 20% will be into this.
A timely topic. I've seen same result when I check usual text typing result.

Selection::Collapse() calls both nsRange::SetEnd() and nsRange::SetStart():,5252

This is redundant and causes a call of nsContentUtils::ComparePoints():,1247

It seems that just omitting the call of nsRange::SetEnd() fixes this bug.
Assignee: nobody → masayuki
I profiled this again with attachment 8848015 [details].

Then, I see that the large part of the case is creating, destroying ranges. If old range is not grabbed by the others, i.e., the refcount is 1, we could reuse the instance. Then, we can skip common ancestor handling that is also expensive.

Additionally, Selection::setFrames() creates two content iterators. If we can omit to create them, we can improve the performance too.
Hi Masayuki, I see that all of the dependencies of this bug have been closed.  What's the current status of this bug?
I guess that we can improve this more if I'll succeed to redesign around nsRange (not yet file a bug) for bug 1367744 (Selection::Extend). But I'm struggling with it for a week due to a lot of oranges. So, currently, I say only, I'm not sure for now.
OK, thanks for the update. :-)
Depends on: 1386342
You need to log in before you can comment on or make changes to this bug.