Released-app results pending
We need our numbers, too.
Lean Term’s own measured performance numbers will be published here once measurements of the released app are ready.
The report will cover typing and terminal responsiveness, visible-ready startup, output, memory, and idle CPU. It will identify the app version, test conditions, sample counts, and measurement limits, with links to supporting evidence.
No performance results for the released app are published yet. This page currently explains the method.
Start with comparable conditions.
Use the same Mac, display, refresh setting, power mode, font, font size, terminal dimensions, and scrollback allowance. Record any setting that cannot be matched.
Test optimized release builds without a debugger. Keep background activity low, alternate the order of the apps, and retain every valid run. Record interrupted or failed attempts separately.
Begin with a clean shell configuration and a simple prompt. Then check your normal shell, prompt, and favorite text-based tools separately. That separates the terminal’s behavior from the cost of a particular shell setup.
Use isolated test settings so your everyday terminal configuration stays intact.
Five checks that answer different questions.
| Question | Check | Report |
|---|---|---|
| Does typing feel connected? | Measure input to a visible shell response. | Median and p95 latency, samples, display settings. |
| How long until I can work? | Fully quit, launch, and observe a ready shell. | Median and slowest run; first launch separately. |
| Does output stay responsive? | Replay identical plain and colored/Unicode text. | Writer time, final visible output, stalls, input behavior. |
| How much memory does it use? | Observe idle, filled scrollback, and sustained output. | One consistent memory metric and sampling times. |
| Does it rest when I do? | Sample CPU over a fixed idle interval. | Average CPU, interval, enabled background features. |
Typing: measure the complete visible response.
The shell’s echo travels back through the terminal before you see it. A callback after a keypress or an internal draw timer can miss part of that experience.
Validate the measurement tool on your Mac first. A repeatable starting point is three batches of 100 samples for each app. Report the median and the 95th percentile (p95), which helps show the slower responses. Synthetic input and screen capture do not establish physical key-to-photon latency.
Startup: stop at a visible, ready shell.
Try ten fully quit-and-relaunch runs with the same shell setup. A process starting or a shell printing a marker does not, by itself, prove that the prompt has been painted. State where your timer stops.
Label the first launch separately. Repeated launches can benefit from filesystem caches, so describe those conditions rather than calling every run a cold start.
Output: watch the screen as well as the clock.
Use the same saved input for every app. Include plain text and a separate mix of ANSI colors and Unicode. Watch for corrupted text, stalls, and whether typing and scrolling remain usable while output flows.
Timing a writer such as cat measures how quickly the terminal accepts its data. The writer can finish before the final text appears. Label that as intake time unless display completion is also measured.
Memory and CPU: give them time.
Choose one memory metric and use it consistently. Resident memory and physical footprint describe different things; do not mix them in one comparison. Report app/helper processes and shell/child processes separately.
Observe an idle interval, then fill scrollback and run a sustained output loop. Record memory at fixed points and after output stops. Check whether usage settles after caches warm.
Measure CPU over an interval rather than relying on one instantaneous reading. Cursor animation and optional status displays can affect idle use, so record their settings.
Choose useful differences.
Repeat runs before treating a small gap as a product advantage. A result should exceed the measurement uncertainty and normal run-to-run variation.
Check correctness alongside speed: resize and reflow, copy and paste, Unicode and input methods, appearance changes, and a representative text-based tool. A fast timing does not compensate for broken input or missing text.
Publish a short table with exact app versions, hardware and display settings, workloads, run counts, raw samples, and limitations. Describe a winner as the fastest among the tested builds under those conditions.
For Lean Term, responsiveness comes first; memory and startup follow closely. Local prototype trials helped us select Swift, AppKit, and SwiftTerm with CoreGraphics/CoreText for v1. Read the stack rationale, including why Rust remains a future option. The released app’s measured results are still pending.
Tools and source documentation.
- Typometer describes its generated-input and screen-capture approach. Validate compatibility and permissions before collecting samples.
- vtebench measures terminal throughput and explains its scope; it does not establish input latency or frame rate.
- SwiftTerm’s performance guide distinguishes engine, rendering, and in-app measurements.
Tool behavior and source versions can change. Record the exact versions used in a published result.