Repository navigation
perf: send an opened document across IPC once - #320
Merged
Merged
Conversation
The openPath, openDialog and activateTab replies echoed the full
FileTruthOpenReplyV1 that main had just published on documentOpened.
The renderer adopts the event and reads only ok from the reply, yet the
8 MB note was serialised twice and the preload re-hashed both copies in
plain-JavaScript SHA-256 (~250 ms each on the huge bench document).
The replies now name the note ({ path, documentId }); the document
travels once, on the event every open and activation already publishes
before replying. The reply validator refuses a reply that carries the
document again.
Packaged Linux bench, 5 runs: huge open 2226 -> 1694 ms, large
797 -> 674 ms.
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The
openPath,openDialogandactivateTabreplies no longer carry the document. They name the note ({ path, documentId }), and the document reaches the renderer once, ondocumentOpened. Every open and activation already publishes that event before it replies.Why
A packaged renderer CPU profile of opening the 8 MB bench document showed the preload spending ~490 ms in
isNotoDocumentWire, almost all of it in its plain-JS SHA-256 of the text. That check ran twice per open: once for thedocumentOpenedevent (whichApp.tsxadopts) and once for the invoke reply, which echoed the sameFileTruthOpenReplyV1but was only read forok. Main also serialised the ~24 MB payload twice.WorkspaceOpenReplyV1.openedis nowWorkspaceOpenedNoteV1 | null. Anullstill means a dismissed dialog or a tab that is not open.session.openPathreturns an internalWorkspaceSessionOpenV1(main keeps the full reply per tab). The narrowing happens at the IPC boundary inopen-reply.ts.Measured
Packaged app, Linux x64 under Xvfb,
BENCH_RUNS=5 BENCH_IDLE_LAG=0, same box, before (main33db02c) and after:The Linux baseline matches the macOS CI run on
e6d373c(huge 2,137 ms). ProfiledopenPathto first paint: 2,264 → ~1,645 ms.Verification
pnpm typecheckandpnpm testpass (2,231 tests), including the newworkspace-open-reply.test.ts.Next residual (huge, from the same profiles)
main
parseDocument~320 ms (about half is building stand-in mdast that engine-owned blocks never read), the one remaining preload hash ~200 ms,docFromSpans~140 ms,EditorState.create~110 ms (typoraMarks fullScan ~50 ms), andcreateEnrichFlagsre-runningcanSkipDialectEnrich~50 ms.