# Codex performance trace analysis

Analyzed locally on 27 September 2026. The dominant bottleneck in both recordings is the main UI renderer repeatedly recalculating CSS styles. The later recording also shows substantial layout and compositor preparation on that same thread. This blocks input handling and frame production.

## Recordings and measured costs

| Measurement | Earlier recording | Later recording |
|---|---:|---:|
| File | `codex-trace-1790529191578.pftrace` | `codex-trace-1790533571556.pftrace` |
| Size | 48,770,442 bytes | 136,836,008 bytes |
| Actual recording duration | 15.51 s | 38.53 s |
| Main renderer process ID | 532 | 14384 |
| Main renderer profiler initialization | 3.138 s | 3.182 s |
| Analyzed interval after renderer profiler initialization | 12.19 s | 35.19 s |
| Main-thread task elapsed time in that interval | 8.10 s | 27.80 s |
| Main-thread task CPU time | 7.75 s | 26.62 s |
| CSS style recalculation | 6.178 s | 16.728 s |
| CSS style recalculation CPU time | 6.008 s | 16.216 s |
| Style recalculation events | 661 | 1,225 |
| Layout | 0.023 s | 2.121 s |
| Paint artifact compositor update | 0.517 s | 4.149 s |
| Main-thread tasks longer than 50 ms | 76 | 186 |
| Main-thread tasks longer than 100 ms | 2 | 84 |
| Longest main-thread task after profiler initialization | 140.8 ms | 1,666.3 ms |
| Median recorded mouse-down latency | 79.1 ms | 285.8 ms |
| Maximum recorded mouse-down latency | 157.7 ms | 3,142.0 ms |

These are different interaction recordings, not a controlled before/after benchmark. Raw event counts should therefore not be compared without accounting for duration and actions.

Style recalculation accounts for approximately 76% of the earlier renderer task time and 60% of the later renderer task time. In the later trace, style recalculation, layout, and compositor preparation together account for about 83%. CPU time closely follows elapsed time: this is actual work occupying the renderer, rather than predominantly a wait on a server or another process.

## What triggers it

### Application-menu hover and React updates

The strongest specific source attribution is the custom application menu. CPU samples contain this path:

```text
menu onPointerMoveCapture (Oe)
  -> menu trigger hit testing (se)
    -> getBoundingClientRect()
```

The installed `app-initial-ff48311587c5.js` confirms that `se` searches the menu triggers and reads their bounding rectangles. `Oe` calls it during pointer movement and can switch the active menu. The relevant profile source locations are zero-based line 1606, columns 230743 and 233241; human-facing line 1607.

The traces also show heavy React commit paths ending in `setAttribute`, and focus/geometry/style reads in menu-related code. These updates and synchronous reads repeatedly trigger expensive style work. This establishes the costly interaction path; it does not establish which individual CSS selector makes each recalculation so expensive.

In the earlier recording, two pointer-move paths alone account for 4.658 seconds of style recalculation: 2.533 seconds under React's scheduled update callback and 2.125 seconds under a wrapped input callback. The equivalent two paths account for 5.397 seconds in the later recording. The wrapper itself is Sentry instrumentation; its appearance does not mean Sentry causes those descendant costs.

Some individual style updates touch thousands of elements. Recorded `UpdateLayoutTree` element counts reach 2,582 in the earlier trace and 6,466 in the later one. This measures elements updated by an event, not the total DOM size or conversation length.

### Additional costs in the later recording

The later trace also contains sampled work in:

- `thread-panel-toggle-button` and `Iti`/`Fti`: the installed source shows a synchronous React update while changing the chat/content split presentation, followed by focus restoration.
- `thread-user-message-navigation-rail-app`: its `it` helper reads offsets and dimensions and adjusts scrolling to keep an item visible.
- `remote-hosted-pip-anchor-bridge`: it observes layout changes and reads computed styles and bounding rectangles to position a floating surface.
- `review-file-tree-side-pane`: geometry reads appear under the panel-toggle call path.

These identify additional contributors to synchronous UI layout work. Their presence alone does not establish that disabling any single feature would eliminate the problem.

## A representative freeze

At 24.696 seconds after recording starts in the later trace, renderer task `1263505` lasts **1.666 seconds** and consumes **1.601 seconds of CPU time**. Within that task are **76 style recalculations totaling 1.221 seconds**. The task services multiple queued input callbacks while producing a frame; it is not necessarily one click handler.

Immediately before it, task `1235396`, at 23.762 seconds, lasts 933 ms and includes another 42 style recalculations totaling 696 ms. This backlog explains why measured mouse-down response times can exceed three seconds even though the longest individual post-startup task is shorter.

## What the evidence does and does not support

- **High confidence:** repeated styling and layout work on the app's renderer main thread causes the captured UI stalls. The named native events, CPU timings, JavaScript samples, and installed source agree.
- **High confidence:** starting the profiler adds a separate approximately 3.1-second renderer pause in each recording. Those pauses were excluded from the ongoing-performance figures above.
- **Low contribution here:** major and minor garbage-collection pause events total about 40 ms in the earlier interval and 100 ms in the later interval. They do not explain the multi-second stalls. These totals exclude incremental/background GC work and should not be treated as total GC CPU usage.
- **Not established:** the exact problematic CSS selector, whether an unnecessarily large mounted UI amplifies the cost, or whether this is a regression from another app version. The captures do not include the selector-level evidence or controlled comparison needed to settle those points.
- **Scope:** these are app/Chromium traces, not complete Windows system profiles. They strongly localize these stalls to the renderer but cannot rule out every unrelated system issue. They do not diagnose model generation latency.

## Practical next steps

The most useful controlled comparison is the same chat with the application menus closed, then repeated menu hover, followed separately by opening/closing the right panel. Allow the initial profiling pause to finish before each test. This would measure how much each identified interaction contributes.

For an app developer, the first targets are repeated menu geometry reads during pointer movement, style invalidation caused by menu/React state changes, and synchronous layout reads during panel and navigation updates. Cache menu geometry until it changes, batch DOM writes and reads, and use selector/invalidation profiling to establish why a small interaction restyles thousands of elements. These are investigation/fix directions, not changes applied here.

## Method and verification

Read the original trace files without modifying them using the official [Perfetto Trace Processor](https://perfetto.dev/docs/analysis/trace-processor), version 58.2. The Windows executable was downloaded from the URL in the official launcher manifest and checked against its SHA-256. Analysis stayed local; neither trace was uploaded.

Used recording start/stop metadata rather than the earliest asynchronous slice timestamp, which can predate recording. Excluded the main renderer's `CpuProfiler::StartProfiling` interval. Analyzed process/thread identity, nested slices, CPU durations, input latencies, and sampled JavaScript stacks. Avoided adding nested wrapper durations together as if they were independent work. The later trace's headline styling/layout/task figures were independently re-queried directly from the original trace and matched the SQLite-derived analysis. Neither import reported data-loss or error statistics.

Inspected matching JavaScript from installed app version `26.924.2738.0` read-only. Source maps were not present in its archive. No app settings or installed files were changed.

Detailed measurements and event IDs are in [codex-trace-metrics.json](codex-trace-metrics.json).