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

Cerrado
  • ¿Algo no está bien?
#579 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
frontend, performance

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
2
Forks
0
Merge medio
1 d 6 h
PR fusionados (30 d)
88

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sillsdev/interlinearizer-extension

Todos los issues de sillsdev/interlinearizer-extension

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.