Bug 13682 – REGRESSION (r21270): Selection and Find are very slow

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

Selection and Find performance has regressed significantly. For example, go to the URL and try to drag to select the text "The text contained within the option element" or do a Find and Find Next for the string "option".

I am going to try to narrow down the regression window.

[Justin Garcia]

Brady narrowed this down to r21270.  Here's some discussion from the radar (<rdar://problem/5193416> REGRESSION: Selection on large pages extremely slow):

5/10/07 12:10 PM Justin Garcia:
Looks like most of the time is being spent in currentTextBreakLocaleID() from TextBreakIteratorInternalCUMac.mm.  Here's a comment from that function:

// NOTE: this abviously could be fairly expensive to do.  If it turns out to be a bottleneck, it might
// help to instead put a call in the iteratory initializer to set the current text break locale.  Unfortunately,
// we can not cache it across calls to our API since the result can change without our knowing (AFAIK
// there are no notifiers for AppleTextBreakLocale and/or AppleLanguages changes).

5/10/07 12:16 PM Justin Garcia:
Strangely though, it doesn't look like calling currentTextBreakLocalID() every time we need to find the next sentence boundary was new in Steve's patch.

5/10/07 12:36 PM Justin Garcia:
Since we called currentTextBreakLocalID() under the same circumstances before Steve's patch, and since his patch didn't appear to change that function, I would guess that the regression happened in r21222, when we started passing the grammar checking code sentence sized chunks in respondToChangedSelection.  We could conditionals the creation of those sentence sized selections on editor()->isGrammarCheckingEnabled(), but then we'd still have to deal with the regression on Leopard.

[Brady Eidson]

<rdar://problem/5193416>

This regressed in r21270

(In reply to comment #1)
> Brady narrowed this down to r21270.
[...]
> I would guess that the regression happened in r21222, [...]

Just to clarify: r21240 is fast and r21272 is slow, so r21222 alone did not cause the regression.

[Sam Weinig]

Mitz, did the change for http://trac.webkit.org/projects/webkit/changeset/21611 fix this for you?

Yes!