perf(desktop): paginate usage activity

[Phoenix500526]

Summary

The slowdown came from Settings → Usage → Activity log rendering every
matching record whenever the tab was opened. With hundreds of records, React
rebuilt the entire table—including per-row tooltips and actions—on every visit.

Paginate the log at 50 records per page so only the visible rows are mounted.
Searching, changing status, or clearing filters returns the table to the first
page.

Fixes #4531

Verification

• npm --workspace @maka/desktop run typecheck
• npm exec -- biome lint on the changed TypeScript files
• npm run format:check (1,857 files)
• npm run check:renderer-architecture -- --base upstream/main (61 tests)
• npm --workspace @maka/desktop run build-storybook
• npm --workspace @maka/desktop run smoke:storybook (502 renders)
• Deterministic 409-record render benchmark, 10 alternating runs per variant
  on the same build: all rows median 1,616.9 ms / p95 1,670.2 ms; 50 per page
  median 74.0 ms / p95 80.0 ms; 21.9× faster by median

The benchmark measures Activity log rendering only; it does not include
loading the usage history from the backend.

UI

Before Change

After Change

Benchmark result

Save this snippet as /tmp/maka-usage-benchmark.cjs, then run it from a Maka
checkout with dependencies and Playwright Chromium installed.

/* benchmark.cjs */
const { execFileSync } = require('node:child_process');
const { mkdirSync, mkdtempSync, readFileSync, rmSync, symlinkSync, writeFileSync } = require('node:fs');
const { tmpdir } = require('node:os');
const { join } = require('node:path');
const { pathToFileURL } = require('node:url');

const repo = execFileSync('git', ['rev-parse', '--show-toplevel'], { encoding: 'utf8' }).trim();
const temp = mkdtempSync(join(tmpdir(), 'maka-usage-benchmark-'));
const env = { ...process.env, CACHE_DIR: join(temp, 'cache') };
const run = (command, args, cwd) => execFileSync(command, args, { cwd, env, stdio: 'pipe' });
const { chromium } = require(require.resolve('playwright', { paths: [repo] }));
const vite = pathToFileURL(require.resolve('vite', { paths: [repo] }));

function patch(file, before, after) {
  const source = readFileSync(file, 'utf8');
  if (!source.includes(before)) throw new Error(`Benchmark fixture is outdated: ${before}`);
  writeFileSync(file, source.replace(before, after));
}

function prepare() {
  const source = join(temp, 'source');
  const archive = join(temp, 'source.tar');
  mkdirSync(source);
  run('npm', ['--workspace', '@maka/desktop', 'run', 'build:workspace-deps'], repo);
  run('git', ['archive', `--output=${archive}`, 'HEAD'], repo);
  run('tar', ['-xf', archive, '-C', source], repo);
  symlinkSync(join(repo, 'node_modules'), join(source, 'node_modules'), 'dir');
  const nestedModules = join(source, 'apps/desktop/node_modules');
  mkdirSync(join(nestedModules, '@vitejs'), { recursive: true });
  symlinkSync(join(repo, 'apps/desktop/node_modules/@vitejs/plugin-react'),
    join(nestedModules, '@vitejs/plugin-react'), 'dir');
  patch(join(source, 'apps/desktop/src/renderer/settings/usage-settings-page.tsx'),
    'pageSize={USAGE_REQUESTS_PAGE_SIZE}',
    "pageSize={Number(Reflect.get(globalThis, '__usageBenchmarkPageSize')) || USAGE_REQUESTS_PAGE_SIZE}");
  run('npm', ['run', 'sync:model-metadata'], source);
  run('npm', ['--workspace', '@maka/desktop', 'run', 'build-storybook'], source);
  return join(source, 'apps/desktop/storybook-static');
}

function waitForTable(page, columns, rows) {
  return page.waitForFunction(({ columns, rows }) => [...document.querySelectorAll('table')].some(
    (table) => table.querySelectorAll('thead th').length === columns
      && table.querySelectorAll('tbody tr').length === rows,
  ), { columns, rows }, { timeout: 10_000 });
}

async function setup(page, url) {
  await page.goto(url, { waitUntil: 'networkidle' });
  await page.waitForFunction(() => window.maka?.settings?.usageStats);
  await page.evaluate(async () => {
    const stats = await window.maka.settings.usageStats();
    const logs = Array.from({ length: 409 }, (_, index) => ({
      id: String(index), ts: 1_800_000_000_000 - index * 60_000, kind: 'model',
      sessionId: `session-${index}`, sessionName: `Benchmark ${index}`,
      provider: 'openai', model: 'gpt-5', inputTokens: 12_400,
      outputTokens: 3_800, costUsd: 0.04, latencyMs: 1_000, status: 'success',
    }));
    window.maka.settings.usageStats = async () => ({
      ...stats, logs, summary: { ...stats.summary, totalRequests: logs.length },
    });
  });
  await page.getByRole('button', { name: 'Refresh usage' }).click();
  await page.getByRole('button', { name: /^Activity log/ }).click();
  await page.getByRole('button', { name: 'Show details' }).click();
  await page.getByRole('button', { name: /^Providers/ }).click();
  await waitForTable(page, 4, 1);
}

async function renderActivity(page, rows) {
  await page.evaluate((size) => Reflect.set(globalThis, '__usageBenchmarkPageSize', size), rows);
  const elapsed = await page.evaluate(async (expected) => {
    const button = [...document.querySelectorAll('button')]
      .find((item) => item.textContent?.trim().startsWith('Activity log'));
    const start = performance.now();
    button.click();
    while (performance.now() - start < 10_000) {
      const table = [...document.querySelectorAll('table')]
        .find((item) => item.querySelectorAll('thead th').length === 8);
      if (table?.querySelectorAll('tbody tr').length === expected) {
        void table.getBoundingClientRect();
        return performance.now() - start;
      }
      await new Promise(requestAnimationFrame);
    }
    throw new Error(`Expected ${expected} Activity Log rows.`);
  }, rows);
  await page.getByRole('button', { name: /^Providers/ }).click();
  await waitForTable(page, 4, 1);
  return elapsed;
}

function summarize(values) {
  const sorted = [...values].sort((left, right) => left - right);
  const middle = sorted.length / 2;
  return {
    median: (sorted[middle - 1] + sorted[middle]) / 2,
    p95: sorted[Math.ceil(sorted.length * 0.95) - 1],
  };
}

(async () => {
  let browser;
  let server;
  try {
    const staticDir = prepare();
    const { preview } = await import(vite);
    server = await preview({ configFile: false, root: join(staticDir, '..'),
      build: { outDir: 'storybook-static' }, logLevel: 'silent',
      preview: { host: '127.0.0.1', port: 0 } });
    const url = `http://127.0.0.1:${server.httpServer.address().port}/iframe.html?id=product-settings-pages--usage-single-provider&viewMode=story&globals=locale:en`;
    browser = await chromium.launch({ headless: true });
    const page = await browser.newPage({ viewport: { width: 1280, height: 900 }, timezoneId: 'UTC' });
    await setup(page, url);
    await renderActivity(page, 409);
    await renderActivity(page, 50);
    const all = [];
    const paginated = [];
    for (let run = 0; run < 10; run += 1) {
      const variants = run % 2 ? [[50, paginated], [409, all]] : [[409, all], [50, paginated]];
      for (const [rows, times] of variants) times.push(await renderActivity(page, rows));
    }
    const allRows = summarize(all);
    const fiftyRows = summarize(paginated);
    console.log(`All rows: median ${allRows.median.toFixed(1)} ms, p95 ${allRows.p95.toFixed(1)} ms`);
    console.log(`50/page:  median ${fiftyRows.median.toFixed(1)} ms, p95 ${fiftyRows.p95.toFixed(1)} ms`);
    console.log(`Speedup:  ${(allRows.median / fiftyRows.median).toFixed(1)}x by median`);
  } finally {
    await browser?.close();
    await server?.close();
    rmSync(temp, { recursive: true, force: true });
  }
})().catch((error) => {
  console.error(error.message);
  process.exitCode = 1;
});

$ cd maka-agent
$ node /tmp/maka-usage-benchmark.cjs
All rows: median 1616.9 ms, p95 1670.2 ms
50/page:  median 74.0 ms, p95 80.0 ms
Speedup:  21.9x by median

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: OpenAI Codex assisted with implementation, tests,
benchmarking, review, and verification.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Phoenix500526]

CC @liuxiaocs7

[liuxiaocs7]

Thanks for working on this. The core pagination behavior appears to address #4531, and CI is green. I found the following issues before merge:

Standards

1. [P2] The new UI implementation bypasses the Astryx surface inventory.

   apps/desktop/src/renderer/features/usage-activity/index.tsx contains a stateful UI component, but the inventory generator excludes every index.tsx as a “barrel re-export.” Consequently, docs/astryx-surface-file-inventory.md excludes this real surface from its coverage gate. Please move the implementation to a file such as ui/usage-activity-pagination.tsx and keep index.ts as a true public barrel, or update the generator so non-barrel index files are inspected.

2. [P2] Preserve full-dataset row semantics for assistive technology.

   The activity table now receives only the current page, but it does not pass Astryx Table's rowIndexStart and rowCount metadata. On page 2, assistive technology therefore sees a new one-row table rather than row 51 of 51. Please pass the page offset and total filtered count through to UsageStatsTable, and add a focused ARIA assertion.

3. [P3] The reset behavior promised by the PR is not covered by tests.

   The updated story verifies navigation to page 2, but it does not verify that searching, changing status, or clearing filters returns the table to page 1. Please exercise these paths starting from page 2 and assert that first-page rows are shown.

4. [P3] The PR is missing UI evidence.

   CONTRIBUTING.md asks UI changes to include before/after screenshots or a recording. Please add one showing the paginated activity log, including the narrow layout if possible.

5. [P3] Prefer the public UI entry for shared primitives.

   HStack is imported directly from @astryxdesign/core even though it is re-exported by @maka/ui. The renderer guidance says new code should reach for Astryx-backed @maka/ui primitives first. Pagination and paginateData can remain direct imports if they are not exposed there.

Spec / verification

6. [P3] The benchmark does not follow the method requested in perf(desktop): Usage activity log is slow with large histories #4531.

   The issue asks for at least 10 switches on both revisions and comparison of median and p95. The supplied script records five timed samples per variant and reports only the average. The summary values (1438.4 ms / 69.3 ms) also differ from the pasted output (1480.8 ms / 72.1 ms). Please rerun and report the requested statistics, or reconcile the documented methodology and results.

[Phoenix500526]

Thanks for working on this. The core pagination behavior appears to address #4531, and CI is green. I found the following issues before merge:

Standards

1. [P2] The new UI implementation bypasses the Astryx surface inventory.
   apps/desktop/src/renderer/features/usage-activity/index.tsx contains a stateful UI component, but the inventory generator excludes every index.tsx as a “barrel re-export.” Consequently, docs/astryx-surface-file-inventory.md excludes this real surface from its coverage gate. Please move the implementation to a file such as ui/usage-activity-pagination.tsx and keep index.ts as a true public barrel, or update the generator so non-barrel index files are inspected.
2. [P2] Preserve full-dataset row semantics for assistive technology.
   The activity table now receives only the current page, but it does not pass Astryx Table's rowIndexStart and rowCount metadata. On page 2, assistive technology therefore sees a new one-row table rather than row 51 of 51. Please pass the page offset and total filtered count through to UsageStatsTable, and add a focused ARIA assertion.
3. [P3] The reset behavior promised by the PR is not covered by tests.
   The updated story verifies navigation to page 2, but it does not verify that searching, changing status, or clearing filters returns the table to page 1. Please exercise these paths starting from page 2 and assert that first-page rows are shown.
4. [P3] The PR is missing UI evidence.
   CONTRIBUTING.md asks UI changes to include before/after screenshots or a recording. Please add one showing the paginated activity log, including the narrow layout if possible.
5. [P3] Prefer the public UI entry for shared primitives.
   HStack is imported directly from @astryxdesign/core even though it is re-exported by @maka/ui. The renderer guidance says new code should reach for Astryx-backed @maka/ui primitives first. Pagination and paginateData can remain direct imports if they are not exposed there.

Spec / verification

6. [P3] The benchmark does not follow the method requested in perf(desktop): Usage activity log is slow with large histories #4531.
   The issue asks for at least 10 switches on both revisions and comparison of median and p95. The supplied script records five timed samples per variant and reports only the average. The summary values (1438.4 ms / 69.3 ms) also differ from the pasted output (1480.8 ms / 72.1 ms). Please rerun and report the requested statistics, or reconcile the documented methodology and results.

Done

[Phoenix500526]

@liuxiaocs7 The latest CI run failed on the unrelated partial-history-notice E2E after 100 other E2E tests passed; this PR does not touch that surface, so it appears to be a timing flake. I do not have permission to rerun Actions—could you please rerun the failed job when convenient? Thanks!

[liuxiaocs7]

Thank you for the analysis. However, I don’t have permission to rerun the CI checks. Could you please push an empty commit to trigger CI again?

[liuxiaocs7]

+1

[Astro-Han]

The pagination itself is sound and the numbers justify it, but one normal-path reset case is missing and the diff is larger than the problem needs.

On the stale approval: the +1 was submitted against 201f380d, and the branch was force-pushed to 189a4215 afterwards. I diffed the PR's own files at both SHAs, and features/usage-activity/index.ts, features/usage-activity/ui/usage-activity-pagination.tsx and settings/usage-settings-page.tsx are byte identical. The only differences are unrelated About-page story fixtures and the two regenerated inventory files, all coming from main. So the delta since the approval is a pure rebase, and the earlier round of feedback (barrel split, rowIndexStart/rowCount, reset coverage, HStack from @maka/ui, the 10-run median/p95 benchmark) is already addressed at this head.

What I verified and found no problem with:

• Totals the user sees are unchanged. The tab count still reads stats.logs.length, recordCount still reads filteredLogs.length, the metric cards still read stats.summary.*, and rowCount passed to the table is the full filtered count, not the page length. rowIndexStart and rowCount are real props in @astryxdesign/core@0.5.2.
• The story fails on old behavior through the production component: without pagination the first render has 53 rows, so toHaveLength(50) breaks. The fixture giving every record the same provider is deliberate and correct here: it keeps the row set constant across the filter change, so returning to page 1 can only come from reset().

P3: shortUsageActivitySessionId has nothing to do with pagination, but it now lives in ui/usage-activity-pagination.tsx and its only caller is still usageSessionDisplayLabel in usage-settings-page.tsx. The move turns a private helper into a cross-file export plus a barrel entry plus a renderer-architecture.json dependency edge, and buys nothing. Leaving it (and the parseDesktopSessionKey import) where it was would shrink this PR.

Also note the branch is currently CONFLICTING. usage-settings-page.tsx is a real code conflict; renderer-architecture.json and the two astryx-surface-file-inventory files just need regenerating after the rebase.

[Astro-Han]

P2: changing the time range does not return the table to page 1. setRange (line 120) only persists, the surface then refetches, and UsageActivityPagination keeps whatever page number it held. A user sitting on page 5 of a 90d history switches to 7d and lands on page 5 of a completely different dataset, or gets silently clamped to its last page. The same applies to Refresh: new records are prepended, so the page 2 window shifts under the reader and boundary rows repeat. The reset wiring added for search, status and clear filters covers the filter paths but not the dataset paths.

Smallest fix: <UsageActivityPagination key={usageDraft.range} items={props.logs} pageSize={USAGE_REQUESTS_PAGE_SIZE}>, so a range change remounts and resets. To cover the refetch shift too, also reset when the items identity changes.

[Astro-Han]

P3: @astryxdesign/core@0.5.2 already ships the seam this reimplements. useTablePagination is the Table plugin for exactly this shape (consumer owns the page state, the plugin renders Pagination around the table, with position, align, size and label). The PR uses paginateData from the same module but routes around the plugin with a render-prop component, a new feature directory and a barrel.

The smaller equivalent: hold page in UsageRequestsPanel (above the showDetails early return), call paginateData directly, and pass the plugin through UsageStatsTable. That deletes features/usage-activity/ entirely, the UsageActivityPage type, and the renderer-architecture.json plus astryx-surface-file-inventory churn, and turns the reset into a plain setPage(1). I have not rendered the plugin's chrome to confirm it matches the current HStack + Pagination layout; if it does not, the fallback is still to move the state into UsageRequestsPanel and drop the wrapper while keeping the hand-placed Pagination.

[Astro-Han]

P3: this helper is about session ids, not pagination, and its only caller is still usageSessionDisplayLabel in usage-settings-page.tsx. Keeping it there (along with the parseDesktopSessionKey import) avoids a new public export, a barrel entry and a dependency edge in renderer-architecture.json.

[Phoenix500526]

@Astro-Han, thanks for the review. I rebased the branch and applied the simplification: the separate usage-activity feature, pagination wrapper, barrel export, and architecture edge are gone, while shortUsageActivitySessionId and parseDesktopSessionKey remain in the existing Usage view. Pagination now uses the Astryx table primitives directly in that view. The story covers returning from page 2 after model search, status changes, clearing filters, range changes, and refresh, and it retains the page-2 rowIndexStart and full rowCount assertions. The PR is now limited to the two existing Usage UI files and their Storybook coverage. The current CI failure is the unrelated transcript-scroll timing test; the pagination and local verification paths are unchanged.

[Astro-Han]

The simplification landed well — the separate feature, the wrapper, the barrel export and the architecture edge are all gone, and the change is now two files that already existed plus their stories. That is the shape I was hoping for. shortUsageActivitySessionId and parseDesktopSessionKey staying put is right.

You're also right about CI: the failure is transcript-scroll.spec.ts:746, unrelated to this PR. I've rerun it. Worth knowing what it actually is, since it will keep hitting your PRs: it expected turn-fixture-1 and got turn-prompt-rail-111 — a turn from a different fixture Session. That is the same fixture race #4714 diagnoses for prompt-rail.spec.ts, showing up in a second spec file.

P2 — page reset is implemented three times over.

UsageRequestsPanel now resets the page from three independent places:

1. key={${usageDraft.range}:${usageRefreshRevision}} remounts the panel on range change and on refresh;
2. useEffect(() => setPage(1), [props.logs]);
3. three manual setPage(1) calls — model filter, status, clear filters.

filteredLogs is memoized on [stats, usageDraft.status, normalizedModelFilter], so its identity already changes for every one of those cases: a filter edit changes normalizedModelFilter, a status change changes usageDraft.status, and both a range change and a refresh produce a new stats. The effect alone covers all three triggers.

So (2) subsumes (1) and (3). Dropping them takes the usageRefreshRevision state with it — it exists only to feed that key — and removes the setPage(1) calls interleaved into the three handlers, which are the part most likely to drift when a fourth filter is added later and someone forgets the reset.

One detail if you keep the effect as the single owner: logs={showRequestDetails ? filteredLogs : []} builds a fresh [] on every render, so the effect fires on each render while details are collapsed. It's harmless today (the state is already 1, so React bails out, and the panel early-returns the Banner anyway), but hoisting that empty array to a module constant makes the dependency honest.

Nothing here is wrong as it stands — the behaviour is correct in all three paths. It's one mechanism where there are currently three.