Ghostty Outperforms Traditional Terminals on Speed and Memory

TL;DR: Ghostty’s single‑threaded renderer, lazy‑tab rendering and scrollback compression make it up to 6× faster and cut memory use by 70‑90 % compared with mainstream Linux/macOS terminals.

Introduction

The terminal emulator is the most frequently used UI component for developers, system administrators, data‑scientists and anyone who works on a command‑line interface (CLI). Yet, despite its ubiquity, the terminal is often treated as a “dumb” text buffer that merely forwards characters from a pseudo‑terminal (PTY) to the screen. Modern terminals such as iTerm2, GNOME Terminal, Alacritty and Windows Terminal have added a rich set of visual niceties—tabs, split panes, image rendering, mouse reporting, and even inline graphics. Those features are valuable, but they also introduce a hidden performance cost: the rendering pipeline competes with the shell’s I/O for CPU cycles and RAM, especially when the output stream is large or when many tabs are open.

Ghostty is a relatively new, open‑source terminal emulator written in Rust that deliberately re‑architects the rendering path. By moving the renderer onto a dedicated thread, suspending work for background tabs, and compressing off‑screen scrollback, Ghostty delivers measurable latency reductions while keeping the memory footprint tiny. The following article expands on the original overview, provides concrete implementation details, presents reproducible benchmark methodology, and offers practical guidance for teams that want to adopt Ghostty in production environments.

The Real Bottleneck in Modern Terminals

Why “just printing text” can be expensive

When a program writes to its stdout, the kernel writes the bytes into a PTY master device. The terminal emulator reads those bytes, interprets escape sequences (ANSI CSI, OSC, etc.), updates an internal screen buffer, and finally asks the graphics subsystem (X11, Wayland, Quartz, or the Windows compositor) to paint the new glyphs. In many traditional terminals, the read‑process‑paint cycle is tightly coupled to the main event loop:

1. Read – The PTY file descriptor becomes readable; the event loop pulls the data.
2. Process – Escape sequences are parsed, the screen model is updated, and a dirty region is marked.
3. Paint – The event loop immediately schedules a repaint, which blocks until the compositor finishes.

If the output stream is bursty (e.g., git log --oneline on a large repository, a make -j build that prints thousands of lines, or a REPL that continuously scrolls), step 3 can dominate the CPU time. The terminal appears to “stall” while the compositor catches up, and the shell may be forced to pause because the PTY buffer fills up.

Real‑world impact

A benchmark performed by the Ghostty 1.4 release team (cited by MakeUseOf) measured the time to pipe a 150 MB file through cat into the terminal:

The same release reported a 6× faster resize when the window was changed while 10 000 lines of scrollback were present. Those numbers translate directly into a smoother experience when scrolling through long logs, when resizing panes in a tiled layout, or when using interactive tools that flood the screen (e.g., htop, ncdu, or a Python REPL).

In a CI‑oriented workflow, the terminal is often used only for log streaming. Even a 0.2 s latency per 10 000‑line chunk can add up to several seconds over the course of a multi‑minute build, increasing the overall wall‑clock time of a job.

Rendering Architecture – Why a Separate Thread Matters

Traditional single‑threaded pipelines

Most “classic” terminals (GNOME Terminal, iTerm2, the default macOS Terminal) run the PTY I/O handling and the UI rendering on the same thread. The main event loop is responsible for:

• ✔️Accepting input from the keyboard/mouse.
• ✔️Reading from the PTY.
• ✔️Updating the internal cell matrix.
• ✔️Triggering a repaint via the platform’s compositor.

Because the compositor may be busy (especially on high‑DPI or Wayland compositors), the terminal can be forced to wait, causing back‑pressure on the PTY. The kernel’s PTY buffer is finite (typically a few kilobytes), so a stalled terminal can cause the producing process to block, slowing down the entire pipeline.

Ghostty’s decoupled design

Ghostty introduces a dedicated rendering thread that consumes a lock‑free queue of glyph batches. The high‑level flow looks like this:

1. I/O Thread – Reads raw bytes from the PTY, parses escape sequences, and pushes glyph batches (a batch = a contiguous run of characters with the same attributes) onto a MPSC (multiple‑producer, single‑consumer) queue.
2. Renderer Thread – Pulls batches from the queue, rasterizes glyphs using the fontdue crate (a fast Rust font rasterizer), and writes the resulting pixel data into a texture that the compositor can present.
3. Main Thread – Handles UI events (mouse clicks, tab switches, configuration reloads) and forwards control messages (e.g., “pause rendering for tab 3”) to the renderer via a second channel.

Because the I/O thread never blocks on the compositor, the PTY never backs up. The renderer can lag behind the incoming stream for a few milliseconds, but the user will still see a smooth scroll as the compositor catches up.

#### Benefits of the separate thread

Lazy tab rendering

Ghostty’s lazy‑tab rendering builds on the separate‑thread model. Each tab has an associated activity flag:

• ✔️Active tab – The renderer receives glyph batches as usual.
• ✔️Inactive tab – The I/O thread continues to parse PTY data, but instead of pushing glyphs to the renderer, it stores them in a compressed scrollback buffer (see the next section). The renderer thread receives a “pause” command and stops consuming from the queue for that tab.

When the user switches to an inactive tab, Ghostty re‑hydrates the compressed buffer on‑demand, pushes the pending glyphs to the renderer, and resumes normal operation. This approach reduces CPU usage for background tabs to near‑zero, while still preserving the full scrollback history.

Implementation Details of Ghostty’s Renderer

Below is a high‑level, language‑agnostic description of the components that make Ghostty’s rendering pipeline fast and memory‑efficient. The actual source code lives in the ghostty GitHub repository (MIT‑licensed).

1. Lock‑free MPSC queue

Ghostty uses the crossbeam-channel crate, which provides a bounded, lock‑free queue. The queue size is configurable (default 64 KiB) to balance latency versus memory pressure. Producers (the PTY parser) push GlyphBatch structs; the consumer (renderer) pulls them in FIFO order.

// Simplified struct definitions
struct GlyphBatch {
    cells: Vec<Cell>,          // each Cell = {ch: char, fg: Color, bg: Color, attrs: Attrs}
    cursor: (usize, usize),   // position after the batch
}

// In the I/O thread
let (sender, receiver) = crossbeam_channel::bounded::<GlyphBatch>(64 * 1024);
...
sender.send(batch).unwrap();

Because the queue is bounded, the I/O thread will block only if the renderer falls behind for an extended period (e.g., when the system is under heavy CPU load). In practice, the renderer keeps up, and the queue rarely fills.

2. Glyph rasterization

Ghostty relies on the fontdue crate for CPU‑only rasterization. fontdue loads a TrueType or OpenType font once, then provides a fast rasterize function that returns an RGBA bitmap for a given glyph size. The rasterizer runs on the renderer thread and benefits from SIMD optimizations on modern CPUs.

let font = Font::from_bytes(include_bytes!("FiraCode-Regular.ttf")).unwrap();
let bitmap = font.rasterize(ch, font_size);

The rasterized glyphs are cached in a per‑font, per‑size LRU cache (capacity 4096 entries). This eliminates repeated rasterization for the same character, which is common in code‑heavy output.

3. Texture upload and compositor integration

On macOS, Ghostty uses Metal to upload the glyph texture to the GPU; on Linux, it uses OpenGL (via glutin) or Vulkan if the user enables the experimental flag. The texture is a simple RGBA8 buffer that matches the terminal’s cell grid (e.g., 80 × 24 cells). Because the texture is updated incrementally (only dirty cells are rewritten), the bandwidth cost is minimal.

4. Scrollback compression

When a line leaves the visible viewport, Ghostty serializes the line’s cell data (character, attributes) into a byte stream and feeds it to a zstd compressor (level 3). The compressed chunks are stored in a ring buffer that can grow up to the user‑configured scrollback limit (default 50 MiB).

# ~/.config/ghostty/ghostty.toml

[scrollback]
max_bytes = 50_000_000          # 50 MiB
compress_level = 3

Decompression happens lazily: when the user scrolls upward, Ghostty decompresses only the needed chunk, reconstructs the cell matrix, and draws it. The cost of decompression is negligible compared with the cost of rendering thousands of glyphs.

5. Configuration hot‑reload

Ghostty watches its configuration file (~/.config/ghostty/ghostty.toml) using the notify crate. When the file changes, the main thread sends a control message to the renderer to update parameters (e.g., font size, scrollback limit) without restarting the process.

Lazy Tab Rendering and Its Impact

How “inactive” tabs are identified

Ghostty marks a tab as inactive under two conditions:

1. Visibility – The tab is not the currently focused tab in the UI.
2. No pending input – The PTY associated with the tab has not received data for a configurable idle timeout (default 250 ms).

When both conditions hold, the I/O thread switches the tab’s mode to Compressed. All subsequent glyph batches are written directly to the scrollback compressor, bypassing the rendering queue.

Quantitative effect

A set of measurements performed on a 2024 MacBook Pro (M2 Max, 32 GB RAM) illustrates the impact:

The idle‑tab savings are most noticeable when developers keep long‑running background sessions (e.g., tail -f /var/log/syslog in one tab while compiling in another). In those cases, Ghostty’s CPU usage can drop by 30‑40 % compared with a traditional terminal that continues to repaint background tabs.

Trade‑offs

• ✔️Pros – Lower CPU, less heat, longer battery life on laptops.
• ✔️Cons – A brief pause (≈ 10 ms) when switching to an inactive tab for the first time, because the scrollback buffer must be decompressed. In practice, this latency is imperceptible for most workflows.

Memory Management – Scrollback Compression in Practice

The memory problem with default terminals

Most terminals allocate a fixed‑size byte buffer for scrollback (commonly 10 MiB). Each line is stored as a UTF‑8 string plus attribute metadata. When a developer runs a verbose build (make VERBOSE=1) or a git log --graph --decorate --oneline on a repository with thousands of commits, the buffer quickly fills, and the terminal starts discarding the oldest lines.

On a 64‑bit Linux workstation, a 10 MiB scrollback buffer can easily expand to 30‑40 MiB of resident memory because each line is stored as a separate allocation (Vec) and the allocator adds overhead.

Ghostty’s approach

Ghostty’s scrollback compression pipeline works as follows:

1. Line serialization – Each line’s cells are serialized into a compact binary format (u32 for the Unicode code point, u8 for the attribute flags).
2. Chunking – Lines are grouped into chunks of 256 lines.
3. Compression – The chunk is compressed with zstd (level 3). The compressed size for typical terminal output is 20‑30 % of the original.
4. Ring buffer – The compressed chunks are stored in a ring buffer that respects the max_bytes limit. When the limit is reached, the oldest chunks are evicted.

Because the compressor works on a per‑chunk basis, random access is cheap: to display line N, Ghostty finds the chunk containing N, decompresses it, and renders only the needed rows.

Real‑world memory numbers

The 70‑90 % reduction is consistent across macOS and Linux, as reported in Ghostty’s release notes.

Benefits for CI agents

CI runners often run inside minimal containers that allocate 2 GiB of memory. A typical job may spawn dozens of parallel builds, each with its own terminal session for log streaming. By switching from a heavyweight terminal to Ghostty, the per‑job RAM consumption can drop by ~30 MiB, allowing ~5‑10 % more concurrent jobs on the same VM without hitting the memory limit.

Configuring Ghostty for Optimal Performance

Ghostty’s configuration is a single TOML file located at ~/.config/ghostty/ghostty.toml. Below is a sample configuration that emphasizes performance while keeping the UI pleasant.

[general]

# Enable hot‑reload of the config file

watch_config = true

[renderer]

# Target frame rate (Hz). Lower values reduce CPU usage at the cost of visual smoothness.

target_fps = 60

# Maximum size of the glyph queue (in number of batches). Adjust if you see “queue full” warnings.

queue_capacity = 65536

# Maximum uncompressed scrollback size (bytes). Ghostty will compress beyond this.

compress_level = 3              # zstd level 3 = good speed/compression trade‑off

# Idle timeout before a tab is considered inactive (ms)

idle_timeout_ms = 250

[fonts]

# Path to a monospaced font that supports Powerline glyphs.

family = "Fira Code"
size = 13.0

# Enable font ligatures (optional, may increase rasterization cost)

ligatures = true

[tabs]

# Maximum number of tabs per window. Ghostty does not enforce a hard limit,

# but keeping it modest reduces UI clutter.

max_tabs = 12

Practical tips

Verifying the configuration

Ghostty ships a built‑in ghostty --debug flag that prints the effective configuration after merging defaults and the user file. Run it once after editing the file:

$ ghostty --debug | grep -i scrollback
scrollback.max_bytes = 50000000
scrollback.compress_level = 3

If you notice that the terminal is still using more memory than expected, enable the runtime statistics overlay (Ctrl+Shift+M) which shows current CPU, FPS, and queue depth.

Benchmark Methodology and Results

To provide reproducible numbers, the following benchmark suite can be used on any Linux/macOS system with Ghostty ≥ 1.4 installed. The suite measures three core metrics:

1. Print latency – Time to render a large file.
2. Resize latency – Time to complete a window resize while scrollback is full.
3. CPU & memory usage – Average CPU % and RSS while the terminal is idle, active, and with background tabs.

Test environment

1. Print latency

# Generate a 150 MiB test file

dd if=/dev/urandom of=bigfile.bin bs=1M count=150 status=none

# Convert to printable ASCII (base64) to avoid binary escape sequences

base64 bigfile.bin > bigfile.txt

# Measure with hyperfine

hyperfine --warmup 3 \
"cat bigfile.txt | ghostty -e bash -c 'cat > /dev/null'" \
"cat bigfile.txt | iterm2 -e bash -c 'cat > /dev/null'" \
"cat bigfile.txt | gnome-terminal -- bash -c 'cat > /dev/null'"

Result (average of 5 runs):

The test isolates rendering time because the command cat > /dev/null discards the data after it reaches the PTY; the only work left for the terminal is drawing the characters.

2. Resize latency

A script resizes the window from 80×24 to 120×30 cells while the scrollback buffer contains 10 000 lines. The script uses xdotool (Linux) or osascript (macOS) to trigger the resize and measures the time until the compositor reports the new size.

#!/usr/bin/env bash

# Fill scrollback

yes "Lorem ipsum dolor sit amet" | head -n 10000 | ghostty -e bash -c 'cat > /dev/null' &
PID=$!
sleep 1   # let scrollback fill

# Resize and time

START=$(date +%s%3N)
osascript -e 'tell application "Ghostty" to set size of front window to {1200, 800}'
END=$(date +%s%3N)
echo "Resize took $((END-START)) ms"
kill $PID

Ghostty’s 6× faster resize is due to the renderer operating on a separate thread and the scrollback compression allowing the UI to discard off‑screen glyphs quickly.

3. CPU & memory usage

Running pidstat -r -u -p 1 30 while the terminal is idle, active, and with three idle tabs yields the following averages (values rounded):

These numbers confirm the 30‑40 % CPU reduction and 70‑90 % memory reduction claimed by the Ghostty team.

Feature Set vs. Performance – The Counterargument

Missing ecosystem features

The absence of built‑in triggers and instant replay is the most frequently cited limitation. However, the same functionality can be achieved with external tools:

• ✔️Triggers → Use script -q -c "your‑command" to capture output and pipe it to a custom logger that executes actions based on regex matches.
• ✔️Instant Replay → tmux capture-pane -S -10000 -E -1 -p > replay.txt provides a full scrollback dump.

For teams that rely heavily on iTerm2’s proprietary features, the migration cost must be weighed against the performance gains. In many CI or remote‑SSH contexts, those UI niceties are rarely used, making Ghostty a compelling default.

Trade‑offs summary

Practical Migration Guide

Below is a step‑by‑step checklist for teams that want to replace their existing terminal with Ghostty. The guide assumes a Unix‑like environment (macOS or Linux).

1. Install Ghostty

#### macOS (Homebrew)

brew install ghostty

#### Linux (binary release)

# Download the latest .tar.gz from GitHub releases

curl -L -o ghostty.tar.gz https://github.com/ghostty/ghostty/releases/download/v1.4.0/ghostty-1.4.0-x86_64-unknown-linux-gnu.tar.gz
tar -xzf ghostty.tar.gz -C /usr/local/bin
chmod +x /usr/local/bin/ghostty

2. Migrate configuration

If you have an iTerm2 or Alacritty config, translate the relevant parts:

Create ~/.config/ghostty/ghostty.toml using the sample above, then run ghostty --debug to verify that the file is parsed correctly.

3. Replace shell launchers

Many developers launch terminals via desktop shortcuts, open -a iTerm2, or gnome-terminal. Update those launchers to invoke ghostty. Example for GNOME:

[Desktop Entry]
Name=Ghostty
Comment=Fast terminal emulator
Exec=ghostty -e $SHELL
Icon=utilities-terminal
Terminal=false
Type=Application
Categories=System;TerminalEmulator;

Place the file at ~/.local/share/applications/ghostty.desktop and run update-desktop-database.

4. Validate performance

Run the benchmark suite from the previous section on a subset of developer machines. Compare the average CPU and RSS numbers against the baseline. Document any regressions (e.g., a custom script that depends on iTerm2 triggers) and decide whether to replace that script with a script‑based alternative.

5. Integrate with tmux (optional)

Ghostty works seamlessly with tmux. If you already use tmux for pane management, you can keep the same workflow:

ghostty -e tmux new-session -A -s main

Because tmux handles its own scrollback, you may want to disable Ghostty’s scrollback for tmux windows to avoid double compression:

max_bytes = 0   # disables Ghostty’s internal scrollback

6. Roll out to CI agents

On CI runners that need a console (e.g., for docker exec -it debugging), install Ghostty as part of the base image:

FROM ubuntu:22.04
RUN apt-get update && apt-get install -y curl \
 && curl -L -o /tmp/ghostty.tar.gz \
    https://github.com/ghostty/ghostty/releases/download/v1.4.0/ghostty-1.4.0-x86_64-unknown-linux-gnu.tar.gz \
 && tar -xzf /tmp/ghostty.tar.gz -C /usr/local/bin \
 && chmod +x /usr/local/bin/ghostty
ENV TERM=xterm-256color
ENTRYPOINT ["/usr/local/bin/ghostty", "-e", "/bin/bash"]

Now each CI job that spawns an interactive console will benefit from the lower RAM footprint and reduced CPU spikes, allowing you to increase the parallelism factor without hitting the VM’s memory ceiling.

When to Prefer Ghostty

Conversely, if your workflow relies on iTerm2’s proprietary features (e.g., instant replay for post‑mortem debugging) and you cannot replace them with external tools, you may keep iTerm2 for those specific tasks while using Ghostty for the bulk of everyday work.

Limitations and Future Roadmap

These roadmap items are tracked publicly on the Ghostty GitHub issue board. Teams that adopt Ghostty early can contribute patches or file feature requests to accelerate the development of missing capabilities.

Conclusion

Terminal emulators have long been treated as a “nice‑to‑have” component, but the benchmarks and architectural analysis presented here demonstrate that rendering efficiency directly impacts developer productivity and CI throughput. Ghostty’s design—decoupling I/O from rendering, lazily suspending background tabs, and compressing scrollback—delivers:

• ✔️Up to 6× faster window resize under heavy scrollback.
• ✔️2.6× faster large‑file rendering (150 MiB test).
• ✔️70‑90 % reduction in resident memory for typical scrollback workloads.
• ✔️30‑40 % lower CPU usage in multi‑tab scenarios.

The trade‑off is a smaller built‑in feature set, but most missing capabilities can be reproduced with existing Unix tools (tmux, script, custom loggers). For teams that run many parallel builds, remote debugging sessions, or long‑running REPLs, the quantifiable latency and memory savings outweigh the loss of niche UI tricks.

Adopting Ghostty is therefore a pragmatic performance upgrade that requires minimal changes to existing workflows: install the binary, drop a TOML config, and optionally replace desktop shortcuts. The resulting environment feels “instant” even when the screen is flooded with output, and the lower RAM footprint enables higher density of terminal sessions on shared CI agents.

Given the current trajectory, it is reasonable to expect that within the next year the major CI platforms will ship Docker images that include Ghostty as the default console, positioning it as a competitive differentiator for cloud‑based build pipelines. Early adopters who make the switch today will enjoy immediate productivity gains and be well‑positioned to benefit from the upcoming plugin ecosystem.

Key takeaways

• ✔️Deploy Ghostty ≥ 1.4 on developer workstations to cut large‑file print latency by ≥ 60 %.
• ✔️Leverage lazy‑tab rendering to keep CPU usage under 3 % in typical multi‑tab sessions.
• ✔️Increase the scrollback limit to 50 MiB without a proportional RAM increase, thanks to built‑in compression.
• ✔️Replace heavyweight terminals on CI agents to lower per‑job RAM consumption and avoid CPU throttling during log streaming.
• ✔️Monitor the upcoming plugin API (v2.0); in the meantime, supplement missing features with tmux, script, or custom logging utilities.

Prepared by the Ghostty performance analysis team, November 2026.

See more articles on The Looplet

Further reading

Read Next

• ✔️Shift Away from Proprietary Game Servers After 2026 Xbox Shutdowns
• ✔️How to Optimize Xbox Games with FSR 4.1 for CrossPlatform Parity
• ✔️Feature Flags vs Age Gates: Which Controls User Access Better

Read next: continue with one of these related guides.