Closed Bug 341420 (SpellCheckPerf) Opened 14 years ago Closed 14 years ago

Speed up inline spellchecker

Categories

(Core :: Spelling checker, defect)

1.8 Branch
x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8.1beta2

People

(Reporter: brettw, Assigned: brettw)

References

Details

(Keywords: fixed1.8.1, perf)

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.
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.
*** Bug 343567 has been marked as a duplicate of this bug. ***
*** Bug 343314 has been marked as a duplicate of this bug. ***
Nominating for blocking.  I'm concerned this may be so severe it should block B1.
Flags: blocking1.8.1?
(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
Flags: blocking1.8.1? → blocking1.8.1+
Target Milestone: --- → mozilla1.8.1beta2
Bug 344895 should fix many of the problems for large text. Bug 344895 comment 8 has some other suggestions.
Depends on: 344895
Depends on: 345048, 345050
Depends on: 345054
Depends on: 345059
Depends on: 345099
Depends on: 345112
Alias: SpellCheckPerf
Depends on: 345751
(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.
Keywords: perf
Whiteboard: fixed by sub-bugs which all have patches
I think performance is pretty good now.
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: fixed by sub-bugs which all have patches
You need to log in before you can comment on or make changes to this bug.