Bug 11460 – REGRESSION (r17276): Find Previous is very slow, especially when wrapping around

• Component: HTML Editing
• Status: RESOLVED FIXED

The Find commands have become very slow, especially Find Previous. For example, go to http://bugs.webkit.org/show_bug.cgi?id=11388 and find "Repo", then press Command-Shift-G a few times.

I tracked the regression down to r17271-r17282, with r17276 being the likely cause.

[John Sullivan]

This is in radar as <rdar://problem/4808375>

It also affects Copy, among other operations.

[Darin Adler]

IRC transcript excerpt:

Mitz: this is the change: http://trac.webkit.org/projects/webkit/changeset/17276
Darin: It's important not to do the work until you actually ask about a range.
Darin: Code is probably is doing too much work as we iterate.

Mitz: this bug reminded me of another "editing" bug
Mitz: when searching for the next rendered position
Mitz: if it's n positions away
Mitz: it takes O(n^2)

(In reply to comment #2)
> Mitz: this bug reminded me of another "editing" bug

I was referring to bug 10735, which is disguised as an SVG bug.

[Justin Garcia]

I was creating two VisiblePositions every time TextIterator exited a node.  Checked in a fix in r17449.  This could still be improved: we should only create VPs when the range that they are used to create is actually asked for.  That would return plainText to its original speed but leave the other users of TextIterator slower than before my change in r17276.  To improve those we'll need to speed up VisiblePosition creation and/or VisiblePosition::next().

[Justin Garcia]

Darin pointed out that Find would be improved by the aforementioned change as well, since it uses ranges but only once it's found the string.

[Alexey Proskuryakov]

*** Bug 11440 has been marked as a duplicate of this bug. ***