348171 - Delete (backspace) is extremely slow in textareas in recent nightlies

Status: RESOLVED FIXED

(Core :: Spelling checker, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Sometime in the last week or so, deleting text in textareas has become very slow on the 1.8branch, although not consistently.  It seems to be worse if you have a bunch of text (e.g., a long paragraph).

I haven't been able to get nightlies on a regular basis for a week or so (and still can't), so I can't tell when it might have regressed, or if it's Camino-only, or anything.  Filing UNCO so that I can get a little help in figuring out those things.

There are also some cases where normal typing and editing are also very slow, but they are even harder to pin down.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This reminds me of bug 272954, which is never a good feeling :(

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I think this is spell-check related; when I turn off spell-checking (and reload the page, which is required, for some reason), I don't notice any lag at all when deleting, even with a long paragraph of text.

I played with this in QuartzDebug a little bit, and I discovered some surprising things:

1) Deleting (aka backspace), even if I'm deleting the *last character in a paragraph*, forces us to redraw the entire paragraph (e.g., the entire pgh flashes red when "identical updates" is on).  

This seems to happen whether spell-check is on or off, so it's not part of this bug--and not how spell-checking is slowing deleting down--but perhaps is an area for improvement.  (By contrast, when typing normally at the end of a paragraph, we only redraw the current and previous line.)

2) With spellcheck on, when deleting at the end of one paragraph, not only do we redraw all of that paragraph, but we also redraw any line in any other paragraph which has an underlined word--twice, it looks like.  This doesn't happen with spellcheck off (i.e., flipping the pref and reloading the page), obviously, since there are no underlined words.

This is perhaps part of the slowdown; why are they being redrawn if no text in/near them is being changed?  Is the spell-checker re-checking the entire textarea on any text change?  If so, that could definitely explain the slowdowns.

Forgot to mention initially that this is in today's 18branch nightly, 2006080901 (1.0+)--I got current today, but my last one was roughly a week old.

cc'ing some folks now that I have a slightly better idea of what's going on (and because we've reached the extent of my perf analysis knowledge!)

Comment 3

[froodian (Ian Leue)]

This regressed between the 2006-08-04-04 nightly and the 2006-08-05-06 nightly.

http://tinyurl.com/g5vzt

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Er, correct bonsai query for that regression range: http://tinyurl.com/klask

There are 3 possibles here, bug 347286, bug 344560 and bug 345112.

We looked at this a little bit on irc, and reverting the number of words back down to 250 (e.g., reverting bug 347286) helps with the lag a little bit, but it's still noticeably slower than before.  Based on the behavior I seemed to observe in QuartzDebug, I'd guess that bug 345112 is the culprit.

Comment 5

[Simon Fraser [no longer active]]

Can someone Shark this and collect some data?

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I have no idea how to use Shark :(

Comment 7

[Stuart Morgan]

I did some deletions in the middle of a bunch of text.  In 08/04, it's basically all just DOM deletion events and text redraw, as expected; spellcheck never really shows up.  In 08/05, with the same text, it looks like this, inside PL_HandleEvent (which also never shows up in the 08/04 samples)

64.7 NSGetModule
64.6   NSGetModule
31.3     nsEditorSpellCheck::CheckCurrentWordNoSuggest
22.3     NSGetModule
13.1       nsTypedSelection::RemoveRange
...

All the NSGetModule stuff is in libspellchecker.  There's no question that the spellcheck code is being called way, way more often in 08/05.

Comment 8

[Mike Schroepfer]

Brett - can you take a look.

Comment 9

[Brett Wilson]

I see this on Linux too. When you press backspace, something is getting confused and we're checking from the cursor to the end of the document.

Comment 10

[Brett Wilson]

Attachment: Patch

Trivial fix. We were returning early from the function before actually finishing what we were supposed to. I don't see any reason to hold off on branch checkin.

Comment 11

[Brett Wilson]

Fixed on trunk. Leaving open for branch checkin.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 233592 [details] [diff] [review]
Patch

a=beltzner on behalf of drivers for the mozilla 181 branch

Comment 13

[Brett Wilson]

Fixed on branch.