Turning on edit for a large File re-highlights it on the main thread (~1 s on 100,000 lines)

Chiusa
  • Qualcosa non va?
#1,258 2 commenti 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
30/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
react, typescript
Ambito
frontend, performance

Direzione di ricerca

Start with the render path named in the profile: FileRenderer.renderFile and renderFileWithHighlighter, plus the worker-pool branch that edit mode skips (see #1144). The updateRenderCache join on onDeferTokenize is a separate, smaller cost you can measure on its own. Done means the edit switch no longer blocks the main thread on a 100,000-line file, shown by a before-and-after profile; the existing render tests should still pass.

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

Descrizione

Summary

Turning on edit for a File with a large file re-highlights it synchronously on the main thread. On a 100,000-line TypeScript file, the switch into edit mode is one long task of about 1.0 s on a CI runner and 0.8–1.6 s on a loaded 8-core Linux box. Viewing the same file with edit off stays smooth because highlighting goes through the worker pool.

Seen on @pierre/[email protected] with WorkerPoolContextProvider and Virtualizer mounted. The same code is still in 1.6.3.

Repro

<WorkerPoolContextProvider …>
  <Virtualizer>
    <EditProvider createEditor={factory}>
      <File file={{ name: 'big.ts', contents: hundredThousandLines }} edit={editing} options={{ … }} />
    </EditProvider>
  </Virtualizer>
</WorkerPoolContextProvider>

Render with editing = false, wait for the view, then set editing = true.

Where the time goes

CPU profile of the switch, longest task (about 1.4 s in that run):

React passive effect (useFileInstance → applyEdit → editor.edit)
  → File.render → FileRenderer.renderFile
  → renderFileWithHighlighter → shiki codeToTokens   ~0.8 s

This looks like the same path as #1144: once an edit session is active, rendering skips the worker branch and highlights synchronously.

A smaller, separate cost: during background tokenizing, FileRenderer.updateRenderCache runs file.contents = lineCache.lines.join("") on every onDeferTokenize batch, even though re-highlighting does not change any line's text. On the same file, skipping the join when no line text changed cut updateRenderCache self time from about 4.1 s to 0.2 s across the session, though it did not shorten the entry task above.

Happy to share the .cpuprofile files.

Lingua principale
TypeScript
Stelle
6.2k
Fork
226
Merge medio
1g 14h
PR unite (30g)
53

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 pierrecomputer/pierre

Tutte le issue di pierrecomputer/pierre

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.