Compared to fastfetch and neofetch

Compared to fastfetch and neofetch

fastfetch

fastfetch is the direct performance benchmark for retch — mature, C-based, and extremely fast. retch aims to beat its runtime (see Continuous Performance Benchmarks) via a concurrent, Rust-based fetch pipeline (see How It Works). Compared field for field since v0.19.0: as of v0.20.10, on Linux, retch is ~3.7x faster in the default mode, ~2.3x in --long and ~1.2x in --full, and level in --short — see Real-hardware benchmarks. On an M3 Pro Mac (v0.20.20) and an Intel + NVIDIA laptop (v0.20.19) retch is ahead in all four modes. Windows has not been measured with the matched configs yet. What retch adds that fastfetch doesn't do:

• Native EDID display parsing (monitor vendor/model, refresh rate, preferred resolution) rather than relying on external tools
• Input-device classification that declines to guess — see Keyboard and mouse classification below, where fastfetch reports a mouse as a keyboard and vice versa on common wireless hardware
• A dedicated --full mode with weather, FUSE-mount-aware disk detection, and full per-sensor temperature readings, layered on top of lighter default modes
• A TOML config engine with CLI-flag/config-file merge logic and --generate-config / --write-config / --merge-config helpers

Field coverage

retch has a field for every fastfetch module it overlaps with. On Linux all of them work, and on macOS all but tpm (deliberately; see below). On Windows six are not implemented yet: keyboard, mouse, brightness, power-adapter, login-manager and tpm, and those fields are simply absent there. Beyond that, where the two tools differ it is deliberate:

• retch reports more:
  • opencl: fastfetch prints a platform version even when the platform exposes no device (normal for Mesa's rusticl until RUSTICL_ENABLE is set). retch reports a platform only when it has a device.
  • disk-io on Windows and brightness on macOS: fastfetch reports neither.
  • Bluetooth on Windows: fastfetch misses Bluetooth LE peripherals.
  • keyboard on macOS: retch finds a connected Bluetooth keyboard that fastfetch misses.
• retch measures differently: for disk-io and net-io, fastfetch sleeps 1 s to sample a rate. retch averages over its own run instead, so the fields add no time in --long, but the figure is an average over the run rather than an instantaneous rate.
• retch reports less: on Linux, keyboards and mice the kernel cannot tell apart are left out rather than guessed. See the next section.

What is still open is platform-specific; see Cross-platform parity.

Keyboard and mouse classification

retch and fastfetch both read the kernel's input-device tables, but they disagree about what to do when those tables are wrong — and on common wireless hardware they are.

This section is about Linux. macOS (supported since v0.16.0) does not have the problem at all: it publishes one IOHIDDevice per HID interface, each carrying its own primary usage, so the kernel states each device's role instead of leaving it to be inferred from capability bitmaps. retch filters to HID usage page 1 and reports usage 6 as a keyboard and usage 2 as a mouse — and a composite device such as an internal keyboard-and-trackpad is correctly listed under both fields, because it genuinely is both. On the machine used for this comparison retch also lists a connected Bluetooth keyboard that fastfetch misses (confirmed connected rather than merely paired via system_profiler).

A peripheral paired through a Logitech Unifying/Bolt receiver is presented to the kernel with a merged capability set: the receiver synthesizes one descriptor covering every device class it can carry. Measured on one receiver carrying an MX Keys keyboard and an MX Master 3 mouse, every kernel-visible signal is identical for the two:

source	MX Keys (keyboard)	MX Master 3 (mouse)
/proc/bus/input/devices handlers	sysrq kbd leds mouse6 event26	sysrq kbd leds mouse5 event25
capabilities/rel	0x1943	0x1943
capabilities/key (alphabet block)	present	present
udev ID_INPUT_*	POINTINGSTICK	POINTINGSTICK
USB HID bInterfaceProtocol	00	00
HID report descriptor prologue	05 01 09 06 a1 01	05 01 09 06 a1 01

The report descriptor looks authoritative and is not: it declares "Usage: Keyboard" for both, because it is synthesized by the receiver driver rather than read from the device.

fastfetch 2.66 classifies from these capabilities, so on that hardware it lists the MX Master 3 and MX Vertical as keyboards, the MX Keys as a mouse, and repeats the MX Vertical in both lists — nine "mice" including the keyboard, both Wacom tablet endpoints, and a phantom PS/2 node.

retch classifies exclusively — a device is a keyboard, a mouse, or neither, never both:

1. Keyboard — a kbd handler and the full alphabetic key block. The handler alone is not enough: power buttons, lid switches, Video Bus nodes, PC speakers, HDMI audio nodes, vendor hotkey drivers and webcam consumer-control endpoints all register kbd.
2. Mouse — a mouseN handler. Covers mice, touchpads and tablets.
3. Both — a merged receiver endpoint. Resolved via the HID++ driver's battery model_name ("MX Keys Wireless Keyboard" / "Wireless Mouse MX Master 3"), the one place on the system where the device's real class survives.
4. Still ambiguous — listed in neither field.

Results are de-duplicated by name, since one physical peripheral routinely registers several evdev nodes under the same name.

Step 4 is a deliberate trade. A paired-but-idle device exposes no battery node, so it is omitted rather than guessed into the wrong list — the same principle as suppressing Users: 0 instead of printing a count that could not be determined. retch will occasionally show fewer devices than fastfetch; it should not show them under the wrong heading. If you would rather see everything the kernel reports, warts included, fastfetch is the better fit here.

Cross-platform parity

Separately from the fastfetch comparison, some retch fields were first implemented only on Linux/macOS. The Windows side was closed as its own series, using native Win32 FFI and no PowerShell spawns (for example domain via GetComputerNameExW and terminal-size via GetConsoleScreenBufferInfo in v0.6.0). What is still open:

• Windows:
  • No keyboard, mouse, brightness, power-adapter, login-manager or tpm yet.
  • In Windows Terminal the logo renders above the text rather than beside it.
  • chafa logo mode is ignored even when requested on the command line.
• macOS: bluetooth shows no on/off state on macOS 26 and later (just Apple Bluetooth), because the power property it reads no longer exists. Until v0.20.16 it reported Off.

Deliberately not implemented on Windows, because there is no faithful native source:

• load: Windows has no load average.
• editor: it comes only from $VISUAL/$EDITOR.
• conhost's terminal-font: only Windows Terminal has a config file retch can parse.

tpm is deliberately absent on macOS: Macs have a Secure Enclave, not a TPM, and fastfetch reports none there either.

Real-hardware benchmarks

The Continuous Performance Benchmarks dashboard tracks runtime on every push to main, but those numbers come from GitHub-hosted CI runners — shared, virtualized, and noisy from run to run. One-off local runs can be skewed too (e.g. a slow FUSE mount adding hundreds of milliseconds to statvfs during disk detection). Neither is a faithful picture of what you'll see on real hardware.

This section collects retch vs fastfetch timings measured on actual physical machines, with CPU/OS context per machine so the numbers are meaningful and reproducible rather than runner-dependent.

Methodology

• Best-of-N warm runs via hyperfine; just bench-compare in the repo automates the pairwise comparison.
• Since v0.19.0 each mode is matched field for field: retch [--<mode>] against fastfetch -c benches/fastfetch/<mode>.jsonc, a config generated from retch's own field table (src/fields.rs) by scripts/fastfetch_configs.py, for all four modes. fastfetch's network timeouts are set to retch's (2 s public IP, 4 s weather); its sampling waits keep fastfetch's defaults, because that is a real design difference being measured. domain, domain-search, arch and cpu-freq have no fastfetch equivalent; each config lists them as unmatched.
• Before v0.19.0 the pairs were NOT like for like, although this page said they were: retch --short vs fastfetch -c none, retch vs fastfetch, retch --long vs fastfetch -c all. -c none means "load no config" (fastfetch's built-in 20-module default), plain fastfetch loads the user's own config when one exists, and -c all runs every module. None of those is the set of fields retch shows, so the older tables below compare different workloads. They are kept as history, not as a current claim.
• No FUSE vaults mounted during the run (unmount cryfs/EncFS first — see NOTES.md §3); same terminal and shell for both tools.

Results

Median wall-clock time (lower is better); the Faster column names the quicker tool and by how much. One block per physical machine.

AMD Ryzen AI MAX+ 395 — Fedora Linux 44, x86_64 (matched configs)

Current: retch v0.20.10 · 29 September 2026 · hyperfine -N medians (40 runs short/default, 20 long, 12 full, 3 warmup) · fastfetch 2.68.1 · on AC, powersave governor, quiet platform profile · the matched per-mode configs described above.

Mode	retch	fastfetch	Faster
short	2.62 ms	2.55 ms	level (fastfetch by 0.07 ms)
default	3.91 ms	14.33 ms	retch, 3.66×
long	221 ms	510 ms	retch, 2.30×
full	431 ms	519 ms	retch, 1.21×

What changed between v0.19.0 (below) and v0.20.10, each change measured before and after in one sitting and explained in NOTES.md:

• cpu-usage waits only for what remains of its 200 ms sampling interval after the other probes, not a fixed 200 ms after them (--long 404 → 218 ms). The minimum interval is now --long's floor on Linux and macOS.
• The CPU core string, the interface list and the CPU name moved off the serial path, and probes start before the serial setup so thread wake-up overlaps it (--short ~4.0 → ~2.8 ms). --short differs from fastfetch by a few tenths of a millisecond, and which one leads varies between sittings and with AC vs battery.
• The audio probe stopped scanning the process table and reading /proc/asound codec files, which query the hardware (v0.20.6; default ~6 → ~3.5 ms here, and ~115 ms per run saved on a Raptor Lake SOF laptop).
• Weather is one request to wttr.in instead of two in sequence (845 → 564 ms), and since v0.20.10 over plain HTTP like fastfetch, dropping the TLS handshake (~570 → ~375 ms). That took --full from behind fastfetch to ahead of it. --full is still bound by weather.

v0.20.5 · 28 September 2026 · same run counts · on battery, powersave governor:

Mode	retch	fastfetch	Faster
short	2.88 ms	2.57 ms	fastfetch, 1.12×
default	7.26 ms	14.54 ms	retch, 2.00×
long	232 ms	514 ms	retch, 2.22×
full	642 ms	523 ms	fastfetch, 1.23×

v0.19.0 (the first matched run, kept for comparison) · fastfetch 2.69.0:

Mode	retch	fastfetch	Faster
short	3.6 ms	2.5 ms	fastfetch, 1.4×
default	35 ms	12 ms	fastfetch, 2.9×
long	383 ms	275 ms	fastfetch, 1.4×
full	1.12 s	0.38 s	fastfetch, 2.9×

At v0.19.0 fastfetch was faster in every mode once both tools showed the same fields. Every "retch is faster" figure before that came from comparing different workloads (see Methodology).

• v0.19.0 moved cpu-usage to --long. On Linux and macOS it needs two samples at least 200 ms apart, and that wait was ~80% of the default mode: default fell from 271 to 35 ms on this machine.
• In a fresh fedora:latest container on the same laptop the default mode is level (6.3 vs 6.1 ms), with short 3.6 vs 2.3 ms, long 347 vs 331 ms and full 1.08 vs 0.87 s. So the remaining default-mode gap on bare metal is in probes that find real devices there.
• macOS is measured below; Windows has not been measured with the matched configs yet.

Intel Core i7-1360P + NVIDIA MX550 — Fedora Linux 44, x86_64 (v0.20.19, matched configs)

Dell Inspiron 16 7630 2-in-1, two GPUs (Intel Iris Xe + NVIDIA MX550 render-offload) · 11 October 2026 · hyperfine -N medians (40 runs short/default, 20 long, 12 full, 3 warmup) · fastfetch 2.68.1 · on AC, powersave governor, balanced platform profile.

Mode	retch	fastfetch	Faster
short	3.32 ms	5.81 ms	retch, 1.75×
default	5.78 ms	19.88 ms	retch, 3.44×
long	224 ms	526 ms	retch, 2.35×
full	503 ms	597 ms	retch, 1.19×

• v0.20.19 fixed --short here (v0.20.18 in the same sitting: 8.42 ms, behind fastfetch). The gpu probe read and walked the 1.6 MB pci.ids once per GPU, ~4 ms for the Intel iGPU (its entry is near the end of the file) plus ~1.5 ms for the NVIDIA card, whose name the driver then replaced anyway. retch now takes the name udev resolved at boot, reads the NVIDIA driver's name first, and falls back to pci.ids only when neither has one. The AMD machine above never paid this: AMD names come from amdgpu.ids.

Apple M3 Pro — macOS 27.0.1, arm64 (v0.20.20, matched configs)

MacBook Pro (Mac15,6), 12 cores (6P + 6E), 18 GB · Current: retch v0.20.20 · 14 October 2026 · hyperfine 2.0.0 --shell=none medians (40 runs short/default, 20 long, 12 full, 3 warmup) · fastfetch 2.70.0 · on AC (battery held at 80%, not charging) · the matched per-mode configs described above. A second sitting straight after agreed within ~5% in every mode, and fastfetch's --full did return a public IP and weather.

Mode	retch	fastfetch	Faster
short	6.62 ms	14.61 ms	retch, 2.21×
default	90.1 ms	146 ms	retch, 1.62×
long	228 ms	705 ms	retch, 3.09×
full	430 ms	708 ms	retch, 1.65×

• The default mode is bound by phys-mem (~83 ms in RETCH_TIMING=1), then audio (~51 ms) and display (~30 ms); every other probe is under 8 ms.
• --long sits on its ~200 ms cpu-usage sampling floor (see the Linux block above).
• The v0.20.15 figures below were taken on battery and these on AC, so compare the ratios rather than the absolute times.

v0.20.15 · hyperfine -N, on battery, fastfetch 2.69.0 with benches/fastfetch/<mode>.jsonc:

Mode	retch	fastfetch	Faster
short	7.0 ms	17.0 ms	retch, 2.4×
default	108–126 ms	145–161 ms	retch, ~1.3×
long	231 ms	674 ms	retch, 2.9×
full	500 ms	751 ms	retch, 1.5×

• v0.20.14 fixed the default mode here. phys-disk ran diskutil once per whole disk, serially, ~0.2 s a call: ~1 s of the run. It now reads IOKit (0.15 ms); v0.20.13 measured 305–322 ms in the same sitting.
• v0.20.15 fixed --short (43–46 → 7.0 ms). It was all the disk field: the sysinfo crate's free-space query (CoreFoundation's "available for important usage", ~9 ms per volume). retch now reads statfs, as fastfetch and df do, so on macOS "free" no longer counts purgeable space and can read lower than Finder.

AMD Ryzen AI MAX+ 395 — Windows 11 Pro (build 26200), x86_64

Old methodology. These tables pair retch with fastfetch's built-in default and -c all, not with the same fields. See Methodology above before quoting them.

Re-measured September 2026 · hyperfine with -N (no intermediate shell), 15–20 runs after warmup, medians · fastfetch 2.65.2 · retch v0.17.6. The July 2026 figures for v0.3.50 are kept in the second table below, because the two tell different stories and the older one should not be quoted as current.

Mode	retch	fastfetch	Faster
short (--short vs -c none)	45 ms	79 ms	retch, 1.8×
standard (default vs default)	142 ms	1339 ms	retch, 9.4×
long (--long vs -c all)	424 ms	1488 ms	retch, 3.5×
full (--full vs -c all)	1314 ms	1468 ms	retch, 1.1×

Under those (unmatched) pairs, retch was faster in every Windows mode. --full was the last one behind, and by much more than the v0.13.2 version of this table said: it read 1445 ms against 1334 ms (1.08×), but re-measured before v0.17.6 it was 3226 ms against 1732 ms (1.86×), and --long had drifted from 286 ms to ~900 ms. Two probes were responsible:

• gamepad still spawned PowerShell (Get-PnpDevice, ~2.0–2.5 s inside retch). It is now one native SetupAPI enumeration (~100 ms) applying exactly the same predicate.
• shell reports the shell's version by spawning the shell, which on Windows means starting PowerShell (~200–570 ms). It ran serially after the concurrent probes, so every --long and --full run paid it on the critical path; it now runs inside the concurrent scope. The v0.11.2 sweep below had cleared shell because removing it from a --fields set moved that harness by only 19 ms — but that harness does not model --long, as the same section warns. Absolute elapsed-time marks inside collect() are what found it.

--full's lead is thin and network-bound: its wall-clock is set by weather and public-ip, which fastfetch's -c all runs as well, so the tails overlap (retch's slowest run 1.77 s against fastfetch's 1.60 s). The medians held in both run orders.

Compare the ratios, not the absolute numbers, across these tables. Absolutes drift with how busy the machine is — fastfetch's own -c none reads 78 ms here and 65 ms in the previous table, unchanged binary — while the ratio is the stable claim.

What --short actually cost, and why the previous explanation here was wrong. The v0.13.1 text said a per-field sweep had put the process-startup floor at ~314 ms with 41 of 56 fields inside 20 ms of it, so "the floor itself is the cost… a startup problem rather than a probing one." Every number in that was real and the conclusion was not. Two sysinfo calls were being made on every run regardless of which fields were selected, and both reached for Windows performance counters, whose first touch in a process costs ~180–195 ms:

• System::load_average() was ungated. On Windows sysinfo has no native load average and synthesises one from a PDH counter sampled every 5 seconds into a process-local static that starts at zero — so in a program that exits in well under a second it can only ever return 0.00, 0.00, 0.00. retch never displayed it, and paid ~190 ms for it.
• CpuRefreshKind::everything() asked for CPU frequency on every run. The Cpu field needs only brand and core count, which come from the static CPU list; requesting frequency is what made System::new_with_specifics cost 195.5 ms instead of 0.5 ms.

The sweep could not see this, because its own baseline paid it too. The sweep timed each field against a --fields os control, and --fields os pays both costs — so subtracting the control cancelled exactly the constant being hunted, and "41 of 56 fields within 20 ms of the floor" is that cancellation seen from the other side rather than evidence of a cheap field set. The honest floor is the command that probes nothing: retch --version measures 17.9 ms against fastfetch --version at 46.8 ms, so retch's own startup was never slow — it begins about 2.6× faster than fastfetch. If you sweep fields on any platform, build the baseline from --version, or instrument absolute elapsed time from process start.

July 2026, retch v0.3.50 (kept for comparison):

Mode	retch	fastfetch	Faster
short (--short vs -c none)	164 ms	74 ms	fastfetch, 2.2×
standard (default vs default)	273 ms	1348 ms	retch, 4.9×
long (--long vs -c all)	1554 ms	1340 ms	roughly tied

What changed: retch's Windows gap had been process-spawn overhead — several probes each shelled out to PowerShell (~0.5–1.8 s of interpreter startup apiece), while fastfetch uses native Win32 APIs and spawns nothing. Since probes run concurrently, each mode's wall-clock was set by its slowest spawn. Those probes were migrated to native Win32 FFI, one per release:

• v0.3.44 — net default-route lookup (~977 ms → native), cutting --short ~1149 → ~163 ms.
• v0.3.46 — phys-disk (Get-PhysicalDisk, ~1684 ms) → storage IOCTLs (~210 ms).
• v0.3.47 — phys-mem (Win32_PhysicalMemory ×2, ~600 ms) → GetSystemFirmwareTable SMBIOS (~152 ms).
• v0.3.48 — bluetooth (~1765 ms) → bthprops + SetupAPI (~150 ms). The bthprops half was itself replaced in v0.10.2: it is BR/EDR-only, so it never reported a Bluetooth Low Energy peripheral as connected. Connected devices now come from System.Devices.Connected on each device node via SetupAPI, at no measurable cost.
• v0.3.49 — cpu-usage dropped a serial 200 ms sleep via GetSystemTimes window-diffing.
• v0.3.50 — camera (Get-PnpDevice, ~1359 ms) → SetupAPI (~155 ms). This was the last standard-mode PowerShell pole, so standard mode fell ~1558 → ~273 ms.

Cumulative over the series: short 1149 → 164 ms, standard 1993 → 273 ms, long 3462 → 1554 ms.

• v0.11.2 — dns (Get-DnsClientServerAddress, ~3409 ms) → GetAdaptersAddresses (~385 ms).
• v0.13.1 — battery (Get-CimInstance Win32_Battery, ~2531 ms) → the battery device's own IOCTLs (~10 ms over the startup floor), taking --long from behind fastfetch to ~2× ahead.
• v0.17.6 — gamepad (Get-PnpDevice, ~2.0–2.5 s) → one SetupAPI enumeration (~100 ms). That was the last field that shelled out to PowerShell to query the system. The only PowerShell launch left is shell asking the running shell for its own version, and since v0.17.6 that runs concurrently rather than on the critical path.

(An earlier version of this section said Windows --long was still behind fastfetch, at 3076 ms against 1467 ms. That was true in September 2026 before v0.13.1, and is kept here only as the record of why battery was next; the current figures are in the table at the top of this section.)

Two method notes worth keeping, both learned by getting them wrong. -NoProfile does not help these spawns: bare powershell -Command exit costs 893 ms with a profile and 878 ms without, so the cost is interpreter startup plus real cmdlet work, not profile loading (the ~642 ms profile figure elsewhere in these notes is about pwsh, PowerShell 7, not Windows PowerShell 5.1). And timing a field in isolation does not predict its effect on a mode: shell measures 1284 ms alone but only 19 ms when removed from the full set, because it overlaps other probes.

13th Gen Intel Core i7-1360P — Fedora Linux 44 (Workstation Edition), x86_64

Measured July 2026 · hyperfine, 10 runs after 3 warmup runs · fastfetch 2.65.2 · retch v0.4.3 · no FUSE vaults mounted · just bench-compare.

Old methodology (see above): fastfetch here ran its built-in default and -c all, not the fields retch shows, so this block is not a like-for-like comparison. The matched Linux figures are in the first block of this section.

Mode	retch	fastfetch	Faster
short (--short vs -c none)	9.5 ms	16.7 ms	retch, 1.8×
standard (default vs default)	346 ms	1095 ms	retch, 3.2×
long (--long vs -c all)	469 ms	1097 ms	retch, 2.3×

On Linux — retch's primary target — the concurrent, scoped-thread Rust pipeline is faster than fastfetch in every mode, including --short. This is the mirror image of the Windows machine above, where a fixed process-startup margin still leaves --short behind; here retch leads from the smallest invocation on up. Both figures are each tool's own default invocation (not like for like; see the note above): fastfetch's default and -c all runs both land near ~1.1 s on this machine — a stable, reproducible cost (σ ≈ 10 ms), driven substantially by the package-manager enumeration its default config performs on Fedora — while retch keeps standard mode around ~350 ms and full --long diagnostics under ~500 ms.

(More real-hardware machine blocks welcome — one #### block per physical machine, with CPU/OS context and just bench-compare figures.)

neofetch

neofetch was the original inspiration for this entire category of tool but the repository is archived and no longer maintained (last commit July 2024). retch (like fastfetch) is a spiritual successor: same "logo beside a field list" presentation, but with active development, better performance (compiled Rust vs. Bash), and cross-platform support (Linux, macOS, Windows) rather than Linux/macOS/BSD-only. If you're still on neofetch, migrating to retch or fastfetch gets you the same familiar output with active maintenance behind it.