Open Bug 496217 Opened 14 years ago Updated 4 years ago

delay initialization of spellcheck dict until actually needed


(Core :: Spelling checker, defect, P3)




Tracking Status
status1.9.1 --- wanted


(Reporter: vlad, Unassigned)


(Blocks 1 open bug)


(Keywords: perf, Whiteboard: [ts][fxperf:p3])

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.
Flags: wanted1.9.2+
Flags: wanted1.9.1.x+
Whiteboard: startup → startup [ts]
Flags: wanted1.9.1.x+
taras confirmed this is costly (70ms) -> P1.
Assignee: nobody → rflint
Priority: -- → P1
should delay initialization, and move the dict files into a jar.
Any changes to dictionary package impact l10n repacks, and other variants of builds we do, fwiw.
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.
Assignee: rflint → nobody
Keywords: perf
Priority: P1 → --
Whiteboard: startup [ts] → [ts]
Are you guys aware of bug 468779, some Chromium changes to speed up spellcheck initialization?
Blocks: 447581
We should check to see if this is still a relevant bug.
Whiteboard: [ts] → [ts][fxperf]
I don't remember ever seeing this in my startup profiles, so I doubt this is still done during startup. I don't know if this is done on the main thread or with async I/O, but I hope the later (in which case we could just resolve this as WFM).
Whiteboard: [ts][fxperf] → [ts][fxperf:p3]
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.