大規模ユーザー辞書向けのインデックス/キャッシュを追加

[artin-kagun]

目的

大きなユーザー辞書を使う場合に、毎回すべての辞書項目を動的辞書として走査・投入する負荷を減らします。

#318 で一度まとめて提案していた変更のうち、このPRでは「大規模ユーザー辞書向けインデックス / キャッシュ」に範囲を絞っています。複数辞書管理、インポート / エクスポート、候補欄へのコメント表示は含めていません。

変更内容

• UserDictionaryIndexStore を追加し、ユーザー辞書項目を DictionaryBuilder.exportDictionary で検索用ファイルに変換できるようにしました。
• ユーザー辞書とシステムユーザー辞書に revision を持たせ、辞書項目が変わったときだけキャッシュを古いものとして扱えるようにしました。
• SegmentsManager 側で、現在の入力に関係する動的辞書項目だけを fallback として渡すようにしました。
• usable なインデックスがある場合は converter の user dictionary URL として渡し、インデックス化できない読みだけを動的 fallback に残します。
• インデックスが未作成または古い場合は、従来同様に動的辞書 fallback を使いながら、バックグラウンドで再構築します。
• 同じ revision の再構築が同時に複数走らないよう、簡単な registry を入れています。
• インデックス作成、未対応読みのスキップ、metadata の stale 判定、revision 更新、動的 fallback の対象判定をテストしました。

意図

候補数を上限で切るのではなく、辞書検索の入力経路を converter が扱いやすい形式に寄せることで、変換候補の網羅性を落とさずに大規模辞書の負荷を下げる狙いです。

インデックス化できない読みは捨てず、従来の動的辞書 fallback に残します。そのため、キャッシュ対象外の項目も引き続き変換候補として出せます。

検証

• swift test --disable-sandbox --package-path Core --build-path /private/tmp/azookey-pr-import-export-build
  • 35 tests passed
• git diff --check upstream/main
• swiftlint --quiet --strict
  • この環境では SwiftLint が未インストールのため未実行です。

[ensan-hcl]

@artin-kagun
compile済みのuser dictionaryを利用するのは大筋で良いと思うのですが、revision管理周りが過剰に丁寧に実装されている感じがしてちょっと気になっています。iOS版のazooKeyではユーザ辞書の設定をいじったときにexport保存処理を実行して、その結果を変換側で使う設計で概ね問題なかったのですが、理由がなければもう少し単純な管理に寄せたいです。

[ensan-hcl]

もう少し細かく実装を読んでみたのですが、今のrevision周りの実装はexportを変換のタイミングでやろうとしているのが原因だと思うので、ユーザ辞書を設定し終わったタイミングでexportするようにすることでもっとシンプルにできると思いました。