You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "Astro-Han (via GitHub)" <gi...@apache.org> on 2026/09/03 18:09:09 UTC
[I] tracking(desktop): clear common-path defects and renderer performance debt [maka]
Astro-Han opened a new issue, #4677:
URL: https://github.com/apache/maka/issues/4677
## Goal
The primary path (create Session → type → read the stream → switch Session → change model or permission mode) has no visible defect and stays responsive on long transcripts.
## Common-path defects
- [ ] #4430 archived Sessions remain selected and trigger Skills and Plan queries
- [ ] #3349 permission mode switch Auto → Bypass is not honoured by the next turn
- [ ] #3827 default-model picker in Settings spins on every switch
- [ ] #3362 Goal chip reads "running" while an armed Goal waits for its first turn
- [ ] #3672 connection base-URL gate is looser than the Runtime Host contract and reports a misleading error
- [ ] #3878 agent graph appears frozen while 0/7 operators are running
- [ ] #4502 failed turns hide the provider's own response; show it collapsed for every failure class
## Renderer performance
- [ ] #4269 upward scroll snaps back to the live tail during geometry changes (PR #4259 by liugddx is in review; the `moved` guard shape is still open)
- [ ] #4256 an oversized single Turn defeats transcript render bounds (same PR)
- [ ] #2913 make session data flow incremental and bounded (M4n5ter)
- [ ] #4647 WorkHub Coordination transcript is replayed in full on every open and reconnect
- [ ] #4123 preserve transcript continuity across bounded ranges
- [ ] #4648 flaky e2e: transcript-scroll asserts the tail before a viewport change re-pins it
- [ ] Establish a perf budget in `apps/desktop/e2e/native-transcript-perf.spec.ts`: first paint of a 500-turn Session, scroll LoAF, switch latency; fail CI on regression.
## Rules
- One issue per PR; each PR links back here and states how it was verified (e2e, Storybook, or CDP trace).
- Fixes land on the authority named in the issue; no renderer-side workaround for a Host contract gap.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5879617955
**Correction to my hydration acceptance comment above** (https://github.com/apache/maka/issues/4677#issuecomment-5872906343): hqhq1025's review of #5800 correctly points out that the measured endpoint is Host-client decode (`ClientSessionSubscription.decodeTranscriptPage`), not the Desktop visible point - no `DesktopTranscriptReplica` installation, Electron IPC, renderer update, or paint, and the RPC handlers are invoked directly rather than through protocol transport/serialization.
So the 62.6ms / 95.8ms numbers are a **Host-side proxy metric, not an end-to-end visible-tail result**, and my "PASS, 8.4x headroom" framing against the 800ms UI budget was an overclaim - the proxy passing does not prove the UI budget is met. #5800 will relabel the metric (Host-client decode proxy, no UI-budget verdict) per the review.
Two findings from that measurement survive the correction because they don't depend on the endpoint: the resident tail is bounded (~84 messages / ~20.5KiB, bootstrap fills and stops) regardless of Session length, and full hydration of the same Session costs ~22x the proxy open. Measuring the actual visible point (through `DesktopTranscriptReplica`, IPC and paint) needs an Electron-harness extension - recording that as open acceptance work for this line.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5880503345
Follow-up on the settings-drift side note in my item-4 comment above: a follow-up diagnosis **did not reproduce the drift and found no real-user path**. With every section write-entry in `settings-surface.tsx` instrumented, 35s of pure idle (and 35s after an explicit section switch) in a real Electron + fake-backend run produced zero section changes and zero remounts; the section state has exactly four write entries, all user-driven (initial mount, `request.section` changes from open intents, navigation clicks, and a `maka:jumpToSettingsSection` window event that has zero dispatchers in the repo - a dead listener). Update polling, menus, the e2e fixture, and the app-shell timer were all excluded.
Strongest remaining hypothesis: the observation was measurement-environment-specific. `SettingsModal` is conditionally rendered, so close/reopen remounts the surface, which restores `request.section ?? localStorage("maka-settings-section-v1")` - a driver flow that once visited the About section would land there on any later intent-less reopen, which reads as "drift" to an observer. No issue filed; treating the original note as closed. One design sharp edge noted for awareness (not issue-worthy without a real repro): on remount, `request.section` preempts the user's own in-session click choice.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5870998857
**Acceptance evidence for checklist item 3 — "Remove WorkHub open/reconnect full replay and validate current linkage under recovery/concurrency" (#4647 / #4699).**
Independent reproduction of the on-demand linkage resolution cost reported in the #4699 description, on a different machine and OS (Windows 11, Node 26.10.0, local SQLite, median of 20 samples after 3 warm-ups):
| history (32 targets, all-terminal) | #4699 author-reported | this reproduction |
| --- | ---: | ---: |
| 100 assignments | ~3.3ms | 3.1ms |
| 1000 assignments | ~32.4ms | 32.7ms |
| 6000 assignments | ~193.6ms | 202.8ms |
Fixture: 32 target Sessions, assignments round-robin across targets, every delegation terminal (`delegation_superseded` / `delegation_replacement_aborted` rotation), read through the candidates-page shape `readActiveWorkHubAssignmentsByTarget(targets, cap 1, includeStopped true)` plus a no-cap variant. The harness asserts its own correctness (0 active links expected on the all-terminal history; a `not_owned` stop resolution seeded as a positive control is returned). The measurements confirm the documented residual: resolution is O(A) in the target's own history and the per-target cap does not engage on all-terminal targets, exactly as analyzed in #4699. The WorkHub open path itself issues one bounded linkage read per candidate page (`candidates` maps the page through a single store call), not a transcript replay.
Recovery/concurrency suites on the same head (Windows, `node --test` on built dist):
| suite | result |
| --- | --- |
| storage `workhub-message-assignment.test` (assignment atomicity, terminal matrix, stop/replacement gates) | 11/11 pass |
| runtime-host `workhub-assignment-crash-recovery.test` | 7/7 pass |
| runtime-host `workhub-coordination-coordinator.test` | 30/30 pass |
These cover admission atomicity, terminal filtering for every outcome shape, crash recovery of in-flight assignments, and the stop/replacement gate races that have test coverage. There is no WorkHub-specific two-client UDS suite, and Windows cannot run the UDS family, so transport-level concurrency remains CI territory - I have not run those locally and claim nothing about them.
From my side, the validation half of item 3 is closed on the Windows-runnable paths: open/reconnect no longer replays the full Coordination transcript, current linkage resolves within the author-reported bounds, and the residual O(A) scan is the deliberate, documented trade-off. The remaining sub-item is the terminal-record identity / stop protocol asymmetry named in #4699, which I understand is being tracked separately.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(desktop): clear common-path defects and renderer performance debt [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5530058987
take
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5620362691
The open item "Accept older → newer → latest navigation, retained focus and reading position — #4123 / #4560" now has a design in #5163: the Renderer owns the transcript window (budgets in screens, not Turn counts) and the scroll authority is the single owner of the reading position. #5163 lists the ten navigation scenarios from the post-#4206 fix PRs as one regression line.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5858009757
Fresh startup profile for current `main` (`fffc19fb5`), filling the "re-profile Host startup" acceptance item in the checklist. Method and script: a self-contained `startup-profile.mjs` (runtime-host scripts, runnable locally on Windows and Linux) that seeds a usage-shaped fixture, then reopens the composition and times four anchors per restart — composition open, five-phase domain recovery, first `session.catalog.query`, and orderly close. Happy to open the script as a PR if you want it in-tree.
**Fixture A — 100 Sessions × 3 Turns × 2 artifacts (3 restart rounds, medians):** open 16ms / **recover 159ms** / first query 1.1ms / close 10ms / total 185ms.
**Fixture B — 300 Sessions × 900 Turns × 12,000 artifacts** (the scale class of #4027's historical ~130s startup / ~90s artifact phase): open 14ms / **recover 397ms** / first query 1.2ms / close 23ms / **total 435ms**. Recovery grows 2.5× for 30× the data (sub-linear), stable across rounds.
Reading: the historical 130s/90s artifact-phase costs no longer exist on current main at either scale — the accumulated persistence and recovery work (#5556, #4716, #4037, #4038, #4874 and neighbors) has brought Host restart to sub-second at the 12k-artifact scale. For the still-open budget line ("Host startup, WorkHub and Usage latency — establish comparable current-main baselines"), I'd propose recording **Host restart total p95 ≤ 1s at 12k artifacts** as the baseline budget going forward, with the measured 435ms as headroom. Caveats: single Windows machine, medians of 3 rounds, `FakeBackend` topology (no real model IO); a Linux CI run of the same script would strengthen the baseline. No claims here about WorkHub or Usage budgets — those still need their own numbers.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5880047554
**Acceptance evidence for checklist item 4 - "Bound Usage Activity rendering and record tab-entry latency (#4531 / #4539)" - the tab-entry median/p95 the table asks for.**
Setup: a deterministic 409-record fixture built through the e2e-fixture scenario path (`settings-usage`, fixed clock, 3 connections / 5 models spread: 399 model-call activities = 394 synthetic zero-tool turns + 5 manual, plus 10 tool activities - row counts probe-verified against the SQLite store), and a perf-tier spec (`apps/desktop/perf/`, real Electron window via `_electron`, single worker) that switches away from and back into the Usage tab and samples tab-entry inside the renderer (click timestamp -> rAF-settled table mount, `performance.now()` based).
Measured on current main sources (Windows 11, Node 26.10.0, 12 rounds of warm re-entry):
| metric | value |
| --- | ---: |
| tab-entry median | **134.1ms** |
| tab-entry p95 | 201.3ms (n=12, so p95 = max sample) |
| mounted activity rows | **50** (exactly `USAGE_REQUESTS_PAGE_SIZE`) |
| tab badge (full `activityTotal`) | 409 |
Reading: the 409 rows are no longer mounted on each visit - exactly one 50-row page lands in the DOM while the badge carries the full total, so #4539's pagination holds under the real Electron + Host + storage path, and tab re-entry sits well inside the "no >50ms task" spirit at median with a conservative-bounded p95 (a 12-sample p95 is the max).
Honesty notes: these are **warm re-entry** numbers (snapshot already resident; cold entry not measured separately); no before-build comparison - #4539's parent predates the entire `apps/desktop/perf/` tier, so porting the harness to the pre-pagination UI exceeded the timebox (the spec documents that 409 is the scale that would have mounted unpaginated); single machine, synthetic fixture, author-reported.
Two side finds worth recording: (1) the fixture infra had a real bug - `catchUpModelCallProjection` folds queued runs in a single limited pass, so 400 queued runs materialized only ~a dozen activities; looping to `pendingRuns === 0` fixes it for any large canonical seed (diff archived). (2) During spec iteration, the settings surface's active section drifted to a different section within its wait window (an effect-driven focus migration; trigger not pinned down) - the spec was made immune to it, but if that drift exists for real users it is worth its own issue.
The fixture diff and spec are archived and can land as a perf-spec PR (the #5042 pattern) if the tracker wants them reproducible.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5872928299
**Status inventory for checklist item 2 - "Accept older -> newer -> latest navigation, retained focus and reading position (#4123 / #4560)" - because the architecture the item was written against no longer exists.**
Timeline: #4123/#4560 landed the original bounded-range continuity (merged 09-06). #5163's ten-scenario regression line landed via #5170 (merged 09-11, with an ablation table). Then **#5366 (merged 09-17) replaced that architecture**: load the durable transcript whole (64 MiB cap) and virtualize in the renderer - deleting the renderer range store, gap rows, prefetch, eviction, and the server-side pager, and with them the #5170 regression files (`transcript-navigation-race/-regression/-pager.test.ts`, `transcript-scroll-cost.spec.ts`, `return-to-latest-pin.test.tsx`). So "accept the ten scenarios as one regression line" is no longer the right acceptance shape; below is the scenario-by-scenario mapping onto the current architecture (source inspection at `58d09e0a8`):
| # | scenario | current state |
| --- | --- | --- |
| 1 | rail jump + large scroll without stall | paging semantics replaced by explicit "load earlier"; no like-for-like assertion remains |
| 2 | return-to-latest after deep history | assertion moved into `apps/desktop/src/main/__tests__/transcript-send-viewport.test.ts` |
| 3 | guest Session page back/forward | paging removed; guests have no Turn index (recorded accepted cost in #5366) |
| 4 | reading position across Sessions | `transcript-tail-restore.test.ts` bookmark assertions (switch away/back, reopen) |
| 5 | not yanked to tail while reading history | `packages/ui/src/__tests__/transcript-scroll-authority.test.ts` - fullest coverage (~12 assertions: pin/release/gesture release/re-pin) |
| 6 | oversized Turn readable | tail-restore carries two oversized-earlier-Turn assertions |
| 7 | single rail tick | `packages/ui/src/__tests__/prompt-rail-reading-position.test.tsx` (renamed in #5170, still present) |
| 8 | WorkHub tail convergence | `workhub-coordination-transcript-preload.test.ts` present, not assertion-by-assertion audited |
| 9 | viewport screen-count budget + no >50ms task | **the open gap**: the frame-budget/LoAF spec was deleted with #5366; remaining are `apps/desktop/perf/transcript-memory.spec.ts` (memory return) and `e2e/partial-history-notice.spec.ts` (explicit load past budget) |
| 10 | no IPC while scrolling without paging | dissolved - the paging IPC no longer exists |
Ask for a maintainer ruling on this item: either tick it on the strength of this inventory (scenarios 4-8 carry live assertions; 1/3/10 are dissolved by the #5366 direction the maintainers set), or keep it open for scenario 9's frame-budget assertion - and if so, whether that belongs in a #5366 follow-up rather than a restoration of the deleted #5170 spec, since re-adding the old line would fight the new architecture.
One residual worth a look either way: `desktop-transcript-range-store.test.ts` was still present at the inspection baseline even though #5366 says it removed the renderer range store - unclear whether that is a Main-side tail cache (intentional) or a cleanup leftover.
Source inspection, not a measured claim; happy to run the surviving suites and record pass counts if that helps the ruling.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5871314423
**Re-assessment of the residual full-read cost documented in #4722 ("Still open") - feeding the checklist item "Re-profile Host startup and resolve remaining recovery/batch-retirement costs" (#4722 reassessment).**
Method: fresh store per scenario on current `main` (`5735554b6`), seeded in bulk through `applyChanges` from one properly-created template record (so every stored shape is decoder-valid), one Session holding everything vs. 300 Sessions, median of 20 samples after 3 warm-ups (create: 5 samples), Windows 11, Node 26.10.0, local SQLite:
| records | shape | readAll | listPage(64) | point read | create |
| --- | --- | ---: | ---: | ---: | ---: |
| 500 | one session | 0.8ms | 1.0ms | 1.1ms | 7.0ms |
| 500 | 300 sessions | 0.8ms | 0.7ms | 1.0ms | 7.0ms |
| 6,000 | one session | 10.2ms | 12.5ms | 10.3ms | 16.1ms |
| 6,000 | 300 sessions | 10.0ms | 10.2ms | 10.2ms | 16.1ms |
| 12,000 | one session | 25.2ms | 29.7ms | 26.4ms | 31.9ms |
| 12,000 | 300 sessions | 24.6ms | 24.9ms | 25.0ms | 31.2ms |
Reading:
- **The residual is confirmed and linear on current main.** Every mutation and read pays the full `readAll()` decode (~2 microseconds per record), and shape is irrelevant: a point read costs the same whether the other records share its Session or belong to 300 unrelated ones. That also answers #5038's point-read acceptance question "bounded materialization when unrelated Sessions grow" for current main: **not bounded - it scales with the store**. #4874 (open) is the in-flight bounding change; these numbers are its before-baseline.
- **In absolute terms the cost is modest at every scale observed in practice.** 12,000 records is the largest shape we know of (#4027's original profile; the real workspace in #4722 held 436), and there a point read is ~25ms and a list page ~25-30ms - within the 150ms Session-open budget for one or two artifact touches, though a few more would spend it, and 10x store growth would put single reads past 250ms.
- **Position:** the design-gated mirror/invalidation change named in #4722 stays the right vehicle and does not need to be rushed at today's observed scales. The re-assessment criterion it was waiting on is now on record: revisit priority if stores approach 10x the observed maximum or artifact-heavy workloads land.
Single machine, synthetic records, stated as such per the tracker's acceptance vocabulary.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5892490569
**New measurement relevant to the "long Session @30ms RTT: open to visible tail p95 <= 800ms" budget - the session-SWITCH path at scale is a different, much larger cost than the initial open.**
Setup: real Electron + Host + storage, a 4,000-turn Session (~70MiB transcript), switching away to a small Session and back to the large one (the "older -> newer -> latest navigation" shape), renderer-side sampling to visible tail (`[data-turn-id]` rows + rAF settle), n=12. Two new sibling defect reports came out of the same investigation: #5843 (candidate election storms at larger total store) and #5844 (a 12,000-turn Session fails to open at all).
| scenario | median | p95 |
| --- | ---: | ---: |
| switch back to large Session (RTT 0) | **18.1s** | 18.3s |
| first return to large Session (cold) | 11.1s | - |
| switch to small Session | ~1.6s | - |
| switch back to large Session (**RTT 30ms**, env-gated transport decorator) | **29.6s** | 32.4s |
Reading:
- The hot switch is **~23x the 800ms budget at 30ms RTT** (29.6s). The wait sits **upstream of render/paint**: a title rename trails the tail by only 30-500ms, so the cost is in the session-switch chain (subscription reopen / transcript delivery), not the renderer.
- The hot switch is ~7s **slower than the cold first return** - an overhear/re-subscription churn signal worth its own investigation.
- RTT multiplies the cost by round-trip count: +11.5s at 30ms ~= **190 extra request/response frame pairs** per hot switch. Switch cost is dominated by RTT x frame count, so the lever is round-trip count, not per-round-trip work.
- For contrast, the small-Session switch is ~1.6s and the Host-side decode proxy for a 1,000-turn open was ~96ms (#5800) - the cost is specific to switching INTO a large session.
Caveats: n=12, single machine, synthetic 18KiB-per-turn fixture (a heavy session, plausibly reachable within days of heavy use); RTT injected as an env-gated transport decorator rather than real network; "visible" = rAF settle of tail rows, not a compositor-verified paint.
The two defect reports above may be upstream causes for part of this cost at even larger scales (#5843 makes the Host unavailable entirely at ~360MiB); the numbers here were taken at a scale where the Host is healthy - so the switch-path cost stands on its own.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5894271699
**Local evidence toward checklist item 1 - "hover gains and cold-scroll/AX validation" - now covering all three halves, with one new pathology found and filed as #5842.**
All measurements are local and synthetic (Windows 11, Edge/Chromium headless via CDP against the Storybook surfaces, single machine, author-reported per the tracker's vocabulary). Three passes, newest findings included:
**1. Hover on current main (containment ablation, 8 conditions x 10 sweeps + idle controls).** Across an oversized fixture (1,813 elements) and a 300-small-Turn fixture: hover sweep frame p95 6.6-7.7ms, **zero LoAFs >50ms in all 80 sweeps + 24 idle controls**; the two-tier containment stacking is not more expensive than either single tier (differences within noise). The author-reported 59ms -> 9ms before/after remains author-reported: the public fixture is ~8x smaller than the original ~15k-element A/B and even all-off produces no long frames at this size.
**2. Scaling up found a real pathology - filed as #5842.** At a 360-step expanded process (**14,919 elements**, transcript ~103kpx), pointer movement inside the transcript produces **~100-110ms per frame, 86 LoAFs >50ms per sweep** - and this is **independent of containment** (all-off identical). Root cause pinned with discriminating experiments: hover-chain switching triggers a **near-full-document style recalc** (`Document::recalcStyle`, 109 hits / max 102ms per sweep); the sufficient condition is the **58 design-system hash-class `:hover` rules** (CSSOM-neutralizing them -> 0, the 29 app `.maka-*` rules only partially); `contain: content` does not scope hover invalidation. Fix directions (product windowing for oversized processes / CSS bisect of the rule shape) are under discussion on #5842. A separate amplifier - Storybook's preview highlight tracker forcing `getBoundingClientRect` every frame even with empty boxes - is actionable upstream.
**3. Cold scroll.** Unexpected anchor displacement per 240px scroll step: **median 15.44px** (n=24), an order of magnitude under the historical 239px anomaly; the 1px cold-scroll story assertions pass on both collapsed and live variants.
**4. AX (first time this half has been run).** Full Storybook AX audit: **438 stories / 475 renders, zero failures**; the oversized-related stories (`OversizedTurnHoldsAReadingAnchorOnColdScroll` collapsed + live, `Performance45Tools`) show **zero accessibility violations** with the 1px cold-scroll assertions green. Caveat: local runs use the Edge channel (Playwright chromium download is broken on this machine) - same Blink engine, different binary than CI.
**What item 1 still needs for a full tick:** a managed-CI run of `performance-frontend.yml` on main (35 runs to date are all on feature branches, latest 09-14; I cannot trigger it), and the #5842 fix - whose absorption into the oversized-Turn hover/cold-scroll numbers would be the natural re-measurement.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5968583156
Independent check on the **hover-gains** half of item 1, on current main (`229e1b466`, after #5911/#5937): the #4259 hover amplifier is **no longer reproducible — its trigger is gone, not merely contained**.
**Measurement** (dense oversized-Turn fixture, ~19–20k DOM nodes; 7+7 alternating rounds × 200 synthetic mousemoves through real hit-testing on headless Edge via CDP; A/B by injecting `contain: none` on the `[data-maka-transcript-boundary]` sub-turn rule while keeping turn-level containment, asserted via computed style each round):
| metric | containment ON | containment OFF | #4259 review (on/off) |
|---|---|---|---|
| hover latency p95 (worst round) | 9.6 ms | 9.5 ms | 9 ms / 59 ms |
| settle wall p95 (worst round) | 10 ms | 10 ms | — |
| LoAF > 50 ms per round | 0 in all rounds | 0 in all rounds | 0 / ~20 |
With the containment fully off, nothing pathological appears — the OFF arm is the #4259 "diseased arm", and it is indistinguishable from ON.
**Why (archaeology):** the失效 source was never the containment rule failing. Astryx's `:where(X:hover *)` invalidation rules — checked in both 0.5.2 (the review-era version, from the tarball) and 0.6.3 — hang only on Overlay/Indicator/Switch/TabList marker classes. On current main none of those classes mount anywhere inside the oversized-Turn subtree (#5911 moved the turn chrome to the Astryx layout without them); the review-era whole-Turn invalidation came from old turn chrome that did mount such classes. The containment rules themselves (`chat-message.css:96`, `:161`) are untouched.
**Instrument validation:** forcing a full-subtree recalc (wildcard descendant rule flip + sync style read) costs ~78 ms per invocation on the same fixture — the rig would clearly see the #4259 mechanism if it still fired. One caveat for future CI work: CDP `Performance.getMetrics.RecalcStyleDuration` is blind to these recalcs (reads 0.2 ms under the positive control), so latency-p95 + LoAF + a forced-recalc positive control is the honest measurement triple.
**Implication for item 1:** the hover-gains concern has no remaining object to validate on current main. This is *not* a case for removing the sub-turn containment CSS — its other duties stand and were not measured here; the regression risk to guard in future is Overlay-class chrome entering the Turn subtree, not the containment switch. Boundaries: synthetic sweep ≠ real pointer, headless Edge ≠ the Electron shell (same environment class as the #4259 review), absolute values are not cross-comparable — the comparable quantity is the ON/OFF delta (= 0). Harness and raw data available on request.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5872906343
**Acceptance evidence for the budget line "long Session @30ms RTT: open to visible tail p95 <= 800ms" - first end-to-end measurement of the 1000-Turn hydration shape (#2913 / #2922 / #2937).**
Method: real execution composition (FakeBackend), a 1000-turn Session seeded through `turn.start`, then per-restart `subscription.open` (tail bootstrap) -> production client decode of the tail -> `loadTranscript` full paging, with 30ms RTT injected as 15ms flight latency around every RPC at the composition's public handlers (`subscription.open`, `session.transcript.page`) - so every page and bootstrap pays a real round trip. Windows 11, Node 26.10.0, current main sources (`5735554b6`), 10 rounds, median/p95:
| fixture | open -> visible tail median | p95 | budget 800ms | full hydration (contrast) |
| --- | ---: | ---: | --- | ---: |
| 1000 turns (~3,000 msgs) | 62.6ms | **95.8ms** | PASS, 8.4x headroom | 1,369.7ms (12 pages) |
| 50 turns (150 msgs) | 62.5ms | 72.6ms | PASS | 124.4ms (1 page) |
Reading:
- Open-to-tail is ~1 round trip (30ms) plus server CPU (~30-65ms) and is **independent of Session length**: the resident tail stopped at 84 messages (~20.5KiB) on both shapes - the 16KiB bootstrap fills and stops, exactly the design claim from #2922/#2937.
- Full hydration of the same 1000-turn Session costs 1.37s, 22x open-to-tail - the "open takes only the tail" split is what the budget rests on, and it holds.
- Against #2913's theoretical 150s sequential-transfer floor, current main sits two orders of magnitude under it.
Honesty notes: this is in-process RPC with simulated flight latency - real server CPU and real decode, but no socket/TLS/WS framing or event-loop contention; p95 over 10 rounds is the max sample, so the tail statistic is weak (a re-run with 20+ rounds would firm it); single machine, synthetic fixture, author-reported per the tracker's vocabulary. The harness is uncommitted; happy to land it as a benchmark script PR (same pattern as #5791) if the tracker wants it reproducible.
One side finding: the registered `benchmark:transcript` script (`scripts/../packages/runtime-host/scripts/transcript-data-plane-benchmark.mjs`) currently crashes on main - it calls `store.readTranscriptPageSnapshot`, which no longer exists after pagination moved to the ledger reader. Worth a repair or an explicit retirement.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5870762546
The measurement script from my [09-27 comment](https://github.com/apache/maka/issues/4677#issuecomment-3352218382) is now proposed for inclusion as #5791: a self-contained `packages/runtime-host/scripts/startup-profile.mjs`, registered as `benchmark:startup-profile` alongside the two existing runtime-host benchmarks. The PR body carries the method, the 100-session and 12k-artifact fixture tables, and a same-head verification run. If the tracker wants different anchors or a different fixture shape for the startup acceptance numbers, happy to adjust.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] tracking(perf): bound Desktop and Runtime Host work as history grows [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #4677:
URL: https://github.com/apache/maka/issues/4677#issuecomment-5890782090
Correction to the residual note in my item-2 inventory above: `desktop-transcript-range-store.test.ts` is **not a leftover**. #5366 rewrote the module in place rather than deleting it - what that PR removed was the windowed range semantics (`loadAround`/`loadLatest`/`hasNewer`); the file survives as the renderer's whole-transcript store (`loadEarlier`, tail acknowledgement, cached fallback) with live consumers in `app-shell-effects.ts` and `create-workhub-services.ts`, and the test continued to evolve after #5366 (#5471/#5494/#5566). Resolving the note as no-action.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org