Update the view's whole-draft copy per change instead of fetching it whole

クローズ
  • 何か問題がありますか？
#579 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
42/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
frontend, performance

調査の方向性

Start by tracing onAnalysisChanged, getFullAnalysis, and the view's draft-copy readers named in the issue; identify how changed links and scope can reach the view alongside the touched analyses and forms. Run perf:app on the reference machine and compare flag-on hostEdit p90 with flag-off edit p90 at each tier. Done means every listed reader reflects session changes and the latency gate passes.

索引モデルが issue の本文から書いたものです。

説明

Part of Phase 4 (#427). Blocks 4b (#454). This is the issue that #453's decisions table asks for when the latency gate fails. It targets the measured cause rather than adding an optimistic layer.

Why

On #574's reference-machine runs, flag-on commit-to-render exceeds flag-off at every tier:

Tier edit (flag off), median / p90 ms hostEdit (flag on), median / p90 ms
small 5.1 / 6.1 22.6 / 24.5
medium 66.2 / 70.3 295.9 / 370.3
large-loadable 533.6 / 560.2 2384.7 / 2416.6

Switching off the session-open read (#578) leaves hostEdit unchanged.

Cause

After each change, the session view fetches the whole draft again through getFullAnalysis, and the next edit queues behind that fetch. Local runs on a laptop, medium tier, hostEdit only, 5 runs each:

Variant hostEdit, median / p90 ms
As in #574 667 / 1466
Refresh after each change switched off 233 / 467
Refresh only after changes pause for 500 ms 647 / 1343

Delaying the refresh doesn't help, because gloss commits are spaced further apart than any useful pause. What matters is how long each refresh blocks, and its cost is spread across both processes. Per refresh, on the same medium runs:

Where ms
Host session queue: getWholeDraft copies the draft 115–229
Host thread: JSON.stringify of the draft 47–74
WebView: request to reply, for a 14.85 MB message 874–1280
WebView: JSON.parse 61–115
WebView: long tasks over 5 edits, parse and re-renders included 21 tasks of 64–508 ms, 5742 ms in all

Cutting any one of these leaves most of the cost. Only not sending the whole draft after each change fixes it.

Fetching the whole draft only when something reads it doesn't work either. Some of its readers are always mounted: StaleAnalysesReporter reads useStaleTokenLinks, and the token-level morpheme checks read useMorphemeResetLosesAnnotation and useMorphemePayloadIsSolelyOwned. Those would stop updating after edits.

Scope

  • After a change, update the view's copy of the draft with only what the change touched, instead of fetching it whole. onAnalysisChanged already names the touched analysis ids and forms. The copy also needs the changed links and scope, which the event doesn't list, so the event or a new query must supply them.
  • Keep the whole fetch at session open, and after New, Open, discards and Save, until 5d (#459) removes getFullAnalysis.
  • Every reader of the copy (the stale reporter, the morpheme checks, the catalog, the concordance, the deletion preview and the stale summary) shows each change.

Risk

With the refresh off, medium hostEdit was still 233 ms locally. The rest likely comes from the shard write, which happens before the reply. In the medium dataset the largest book shard is 13.27 MB of the draft's 13.27 MB, so each edit rewrites nearly the whole draft before replying. If the gate still fails after this issue, that write is the next thing to measure.

Done when

  • With the flag on, perf:app's hostEdit p90 is at most 1.2 times the flag-off edit p90 from the same run, at any tier, on the reference machine.
  • Each reader of the whole-draft copy shows changes made through the session.
主要言語
TypeScript
スター
2
フォーク
0
平均マージ
1日 1時間
マージ済み PR（30日）
105

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sillsdev/interlinearizer-extension のほかの issue

sillsdev/interlinearizer-extension の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。