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

Chiusa
  • Qualcosa non va?
#579 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
frontend, performance

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
TypeScript
Stelle
2
Fork
0
Merge medio
1g 4h
PR unite (30g)
99

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sillsdev/interlinearizer-extension

Tutte le issue di sillsdev/interlinearizer-extension

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.