The default bug view has changed. See this FAQ.

delay initialization of spellcheck dict until actually needed

NEW
Unassigned

Status

()

Core
Spelling checker
8 years ago
7 years ago

People

(Reporter: vlad, Unassigned)

Tracking

(Blocks: 1 bug, {perf})

Trunk
Points:
---
Bug Flags:
wanted1.9.2 +

Firefox Tracking Flags

(status1.9.1 wanted)

Details

(Whiteboard: [ts])

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+
(Reporter)

Updated

8 years ago
Whiteboard: startup
Whiteboard: startup → startup [ts]
status1.9.1: --- → wanted
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.

Comment 3

8 years ago
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
You need to log in before you can comment on or make changes to this bug.