Skip to content

Nothing measures the terminal render path, so a runaway renderer cannot be diagnosed #175

Description

@devsuitup

A renderer process burned about 1.2 cores for several minutes and stopped the moment the visible session was switched — which is the expected mechanism, since only the displayed session is parsed and painted. What could not be answered is whether that cost was legitimate.

At the 30 flushes per second the code already caps writes to, 1.2 cores means roughly 33 ms of CPU per frame: an entire frame budget spent on one terminal. Two readings fit the evidence and nothing separates them. The GPU process working set nearly tripled during the episode (112 MB to 290 MB), which is what a glyph atlas rebuild looks like, and onChangeTextureAtlas forces terminal.refresh(0, rows - 1) — a full repaint of every visible line.

The activity trace was running throughout and says nothing about it: it has no category covering handleTerminalData, flushTerminalBuffer or terminal.write. It was also ruled out as the cause, its event rate being anti-correlated with the CPU.

Three counters would have settled it in a minute: writes per second, batch size, atlas rebuilds. This is instrumentation, not a fix — no functional defect is established.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions