341420 - (SpellCheckPerf) Speed up inline spellchecker

Status: RESOLVED FIXED

(Core :: Spelling checker, defect)

Description

[Brett Wilson]

There are some inefficiencies in the spellchecker that should greatly improve performance.

When you move the cursor with the arrow keys, the spellchecker runs. This is needed for "turning on" the underline when a misspelled word is left, but is otherwise not needed. This means we are constantly checking words as the user arrows through a document. Actually checking a word is slow, but just finding the word boundaries also takes some time.

We should remember something like "has spellchecked since last change." If we have spellchecked since the last insert/delete, we should do the current operation when the cursor moves. When this is false, we know we don't need to do this.

Second, dealing with ranges is extremely inefficient. The spellchecking underline is represented as a selection, which is a series of ranges. Whenever wew check a word, we compare it to all ranges in a brute-force manner to see if in intersects. This operation is [number of words to check]*[misspelled words] long, which can be very large.

For single-character inserts which are the common operation, we should be able to more efficiently determine what to do. For example, we should know if the current word is marked as misspelled. If not, and we append another character to it (i.e. type), we don't need to do anything (the current word is never marked as misspelled after edits). This should make typing much more efficient.

Comment 1

[Håkan Waara]

See also bug 343535 (mac-specific, but with a testcase).  I find that doing Undo in a textfield with lots of text is semi-hanging us after 1-2 undos.

Comment 2

[Brett Wilson]

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

Comment 3

[Brett Wilson]

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

Comment 4

[Peter Kasting]

Nominating for blocking.  I'm concerned this may be so severe it should block B1.

Comment 5

[Peter van der Woude [:Peter6]]

(In reply to comment #4)
> Nominating for blocking.  I'm concerned this may be so severe it should block
> B1.
> 

As example of its severity, I had to disable spell checking because of this.
When I edit a large forumpost on moz forum (text size 12kb) it takes 10-15 secs to display the editfield and another 10-15 secs when I paste the new text in place  (athlon 850 + 512Mb). During this period Firefox is totally locked/useless with 100% cpu load

Comment 6

[Brett Wilson]

Bug 344895 should fix many of the problems for large text. Bug 344895 comment 8 has some other suggestions.

Comment 7

[u88484]

(In reply to comment #5)
> (In reply to comment #4)
> > Nominating for blocking.  I'm concerned this may be so severe it should block
> > B1.
> > 
> 
> As example of its severity, I had to disable spell checking because of this.
> When I edit a large forumpost on moz forum (text size 12kb) it takes 10-15 secs
> to display the editfield and another 10-15 secs when I paste the new text in
> place  (athlon 850 + 512Mb). During this period Firefox is totally
> locked/useless with 100% cpu load
> 

to comment further on this...when I also edit moz forum posts firefox hits 100% cpu load when I paste large text and scrolling is severely slowed when scrolling in this area. scrolling makes cpu load 100% all the time with spell checker enabled in the edit field.

Comment 8

[Brett Wilson]

I think performance is pretty good now.