Last Comment Bug 496217 - delay initialization of spellcheck dict until actually needed
: delay initialization of spellcheck dict until actually needed
Status: NEW
: perf
Product: Core
Classification: Components
Component: Spelling checker (show other bugs)
: Trunk
: All All
-- normal with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
Depends on:
Blocks: 447581
  Show dependency treegraph
Reported: 2009-06-03 15:24 PDT by Vladimir Vukicevic [:vlad] [:vladv]
Modified: 2010-03-02 15:57 PST (History)
19 users (show)
vladimir: wanted1.9.2+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Vladimir Vukicevic [:vlad] [:vladv] 2009-06-03 15:24:22 PDT
On a cold startup, initializing spell check (and reading the dictionary files) takes 100ms+.  There should be no reason to do this on startup.  In an ideal world, we would delay until we actually needed to spell check, and would then do the initialization (dict reading) on a thread to avoid getting in the way of the user.
Comment 1 User image Dietrich Ayala (:dietrich) 2009-08-26 09:18:10 PDT
taras confirmed this is costly (70ms) -> P1.
Comment 2 User image Dietrich Ayala (:dietrich) 2009-08-26 09:18:56 PDT
should delay initialization, and move the dict files into a jar.
Comment 3 User image Axel Hecht [:Pike] 2009-09-29 11:38:22 PDT
Any changes to dictionary package impact l10n repacks, and other variants of builds we do, fwiw.
Comment 4 User image Ryan Flint [:rflint] (ping via IRC for reviews) 2009-11-13 14:51:56 PST
The only time we load dictionaries on startup is if you're restoring a session that contains <textarea>s or other inputs with spell checking enabled. I've messed around with a few potential solutions like not initializing spell check until the editor is focused, but most I've tried so far don't seem so great in terms of UX and UI responsiveness.

I think the ideal solution would be to have a way for session restore to mark docshells as being in the background so we can lazily initialize spell check or anything else we'd potentially encounter while restoring a session.

Speeding up dictionary loading and/or offloading it to separate thread are certainly things we can do, but will come at the cost of maintaining our own Hunspell, which without active ownership of this component seems like a losing proposition (Hunspell itself doesn't look like it's had much activity since last year, so maybe we're already headed in that direction).
If do wind up making changes to our in-tree Hunspell, chromium has a binary format for their dictionaries and affix files (bug 468779) which we may want to consider using. The version of Hunspell we have in-tree appears to support some sort of zipped format which might also be an option. I'm not sure JARing the files would win us as much as either of those and might actually wind up being detrimental, since I doubt the vast majority of our users are hitting the init path during startup.
Comment 5 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2009-11-17 11:31:31 PST
Are you guys aware of bug 468779, some Chromium changes to speed up spellcheck initialization?

Note You need to log in before you can comment on or make changes to this bug.