Skip to content

Tui round3 - #108

Merged
fredbi merged 2 commits into
go-openapi:masterfrom
fredbi:tui-round3
Aug 14, 2026
Merged

fredbi merged 2 commits into
go-openapi:masterfrom
fredbi:tui-round3

Conversation

@fredbi

@fredbi fredbi commented Aug 14, 2026

Copy link
Copy Markdown
Member

Change type

Please select: 🆕 New feature or enhancement|🔧 Bug fix'|📃 Documentation update

Short description

Fixes

Full description

Checklist

  • I have signed all my commits with my name and email (see DCO. This does not require a PGP-signed commit
  • I have rebased and squashed my work, so only one commit remains
  • I have added tests to cover my changes.
  • I have properly enriched go doc comments in code.
  • I have properly documented any breaking change.

fredbi and others added 2 commits August 14, 2026 15:38
m opens a card describing the run that just finished: what it allocated,
what it left live, how many objects and collections that took, and how much
the process holds from the OS. A modal rather than another status-line
field, since that line already carries the pane hints, the follow badge and
the search prompt.

The run is fenced three times - before the scan, after it, and once the
document has been rendered as JSON and YAML - so the card separates what
codescan spent from what serializing its result spent on top.

Two things the figures are not, stated on the card where they are read: the
window is process-wide, because the redraw loop and the file watcher
allocate on other goroutines meanwhile; and a rescan is measured while the
document it replaces is still live, so its retained figure reads high by
about one spec.

Duration formatting moves to a humanize package alongside the new byte and
count forms, so the header line and the card cannot drift into two
spellings of the same measurement.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
The run-cost card reports process-wide scalars, and a scalar cannot say
who spent it: while a scan runs, the redraw loop and the file watcher
allocate on other goroutines, and no arithmetic separates them out
afterwards. Start with -profile and each scan is profiled as well, so the
same noise arrives named — a row to discount rather than a confound.

The card then reports, per phase, where the CPU went and what allocated
the memory, by function; a split line at the top recaps the run as ratios
(time, memory, and sampled CPU) so the phase to look at is the first thing
read. It scrolls once it outgrows the terminal.

Both phases are bracketed the same way: a CPU profile each, and an
allocation profile differenced across the fences the cost figures already
use. Rendering is often shorter than the sampler's 10 ms interval and
catches nothing, which the card states — an absent section reads as an
oversight, "nothing sampled" is a measurement.

Flags rather than options-popup rows: runtime.MemProfileRate is meant to be
set once and held for the life of the process, so a mid-session toggle would
make consecutive readings incomparable. -profile-dir says where the five
artifacts land, and the card carries the go tool pprof commands that open
them, -base included so either phase reproduces in the real tool.

What the mode costs itself is disclosed rather than hidden: it collects at
each fence to keep the allocation profile current, so the summary figures
are worse than the same run unprofiled. The profiler's own allocations —
flushing one phase's profile through a compressor, allocating the next
one's buffers — are dropped from the tables, where in the short phase they
would otherwise crowd out its real sites.

github.com/google/pprof/profile reads the profiles back. It is a
self-contained package with no transitive requirements, and it joins this
module rather than the library.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
@fredbi
fredbi merged commit cac6b45 into go-openapi:master Aug 14, 2026
29 checks passed
@fredbi
fredbi deleted the tui-round3 branch August 14, 2026 13:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant