Activity

1. hegjon commented on Sep 4, 2026

   

   hegjon

   on Sep 4, 2026

   ContributorAuthor

   More actions

   Install-speed benchmark of the experiments (QEMU)

   I benchmarked all four linked PRs, plus the current quattro tip as a baseline and an unpublished btrfspack branch, under one harness on 2026-09-04. Every install is an encrypted (LUKS) full-disk autoinstall of the same account and layout. Timing is the installer's own record (state.json span for the Python branches, the omarchy-install-milestone BEGIN→END journal span for the bash branches) — the number each branch's own dashboard renders.

   These are the QEMU results. Real-hardware (ThinkPad X200) numbers will follow in a later comment.

   NOTE1: The bash branches pay a mirror-verification cost off slow media. #132 and btrfspack verify the whole offline mirror before touching the disk, which is cheap from a fast source, but dominates the install off a slow USB stick.

   NOTE 2: Integrity caveat: #113 and #132 land the system on btrfs, which computes and stores a checksum for every block of written data — real integrity work that the raw-restore approaches do not do, and part of what their numbers include. btrfs discourages O_DIRECT, which interacts badly with checksumming: see https://btrfs.readthedocs.io/en/latest/Checksumming.html.

   NOTE3: Verification of the root image and offline mirror happens in the background. Parts of the verification on a interactive install will be done. So this is absolute worst case. Including a pause before starting the install would emulate a user doing a interactive install.

   What was built

   Each ISO was built the same day from the same edge mirror with bin/omarchy-iso-make --keep-pkg-cache.

   Candidate	Commit	ISO size
   quattro (baseline)	2673c613d	6.23 GB
   #108 — install from prebuilt rootfs (unsquashfs)	142f683a9	6.63 GB
   #113 — btrfs send/receive root image	0dcc9baf0	6.84 GB
   #132 — archinstall-bash (carries #113)	8a9d209d9	6.79 GB
   #145 — qcow2 restore + parallel finalize (on #113)	dbffaa6c6	7.02 GB
   btrfspack (unpublished)	6ac4cb48f + local changes	6.83 GB

   Hardware

   QEMU/KVM on a Ryzen 9 9950X host (186 GiB RAM). Guest: 16 vCPU, 16 GiB, Q35/OVMF. Two medium/target combinations:

   Setup	Install medium	Install target
   file	ISO on the host filesystem, cache=none	/dev/nvme0n1p3, Samsung 990 PRO 2TB (S7DRNJ0X926544D), raw partition, cache=none
   USB stick	Kingston DataTraveler 3.0 32GB (E0D55EA573F217A1394E034D), USB 3	same 990 PRO partition

   Results — install time in seconds (mean of 3, encrypted)

   Candidate	file source	USB stick source
   quattro (baseline)	53.1	68.6
   #108 unsquashfs rootfs	40.7	43.5
   #113 btrfs image	39.9	68.3
   #132 archinstall-bash	44.0	99.7
   #145 qcow2 restore	22.9	56.5
   btrfspack	32.3	87.7

   Run-to-run spread was tight (for example #145/file 22.8–22.9, quattro/USB 67.9–69.0). All runs installed the expected package set and booted into the encrypted system.

   Method notes

   • The bash branches (Install with archinstall-bash: moving towards systemd as the orchestrator #132, btrfspack) measure a slightly wider span than the Python branches: their milestone marks the installer handover through the timing-record write, where the Python span is the phase run only. Both are each branch's own reported "installed in" figure.
   • Per-run package counts for the bash branches were not captured (the target unmounts before collection); they install the same invariant root-image set as Install the target from a btrfs root image instead of pacstrapping it #113.
2. hegjon commented on Sep 4, 2026

   

   hegjon

   on Sep 4, 2026

   ContributorAuthor

   More actions

   Follow-up: real hardware (ThinkPad X200)

   The same encrypted installs from the QEMU comment above, run on real, deliberately slow hardware. The QEMU numbers are best cases on a fast host; this is the other end of the range.

   Machine

   • ThinkPad X200 — Intel Core 2 Duo P8400, 2 cores @ 2.26 GHz, BIOS boot.
   • Install medium: Samsung FIT USB drive (0373519050006146) on a USB 2.0 port (~2–3 MB/s writes — the reason the absolute times are large).
   • Install target: internal Samsung PM830 128GB SATA SSD (S0TYN6AC526340).
   • Encrypted (LUKS) full-disk autoinstall, one run per candidate, driven over SSH from the same ISOs used in the QEMU comment.

   Builds (same-day, same edge mirror): quattro 2673c613d, #108 142f683a9, #113 0dcc9baf0, #132 8a9d209d9, #145 dbffaa6c6, btrfspack 6ac4cb48f (+ local changes).

   Results — install time, one run each

   Candidate	Install time	vs baseline
   #108 unsquashfs rootfs	4m 25s (265.4 s)	−36%
   #113 btrfs image	4m 26s (265.6 s)	−36%
   btrfspack	4m 53s (293 s)	−29%
   #145 qcow2 restore	5m 25s (325.2 s)	−22%
   #132 archinstall-bash	5m 57s (357 s)	−14%
   quattro (baseline)	6m 55s (414.7 s)	—

   Every install completed with the expected package set and booted into the encrypted system.

   What stands out

   • Install from a prebuilt rootfs image instead of pacstrapping 925 packages #108 and Install the target from a btrfs root image instead of pacstrapping it #113 win, within a fifth of a second of each other. The prebuilt-image approach is the biggest, most robust gain on this hardware — a third off the baseline.
   • Speed up installs with compressed qcow2 restores and parallel finalization #145 loses the lead it had in QEMU. From a fast source in QEMU it was the fastest at 22.9 s; here it is second-slowest. Its parallel finalization has only two slow cores to spread across, and the qemu-img restore plus the LUKS lifecycle work costs more than a plain btrfs receive. The optimization is real but it is tuned for a machine the X200 is not.
   • Install with archinstall-bash: moving towards systemd as the orchestrator #132 is slow off this medium. It verifies the entire offline mirror before touching the disk, reading it off the USB 2.0 stick — the same penalty it pays off a slow stick in QEMU. On fast media that verification is nearly free; here it dominates.
   • btrfspack sits between the image branches and Speed up installs with compressed qcow2 restores and parallel finalization #145 at 293 s.

   Notes

   • Install the target from a btrfs root image instead of pacstrapping it #113 and Install with archinstall-bash: moving towards systemd as the orchestrator #132 land the system on btrfs, which checksums every written block — integrity work the raw-restore paths skip. btrfs also discourages O_DIRECT: https://btrfs.readthedocs.io/en/latest/Checksumming.html
   • Package counts differ from the QEMU runs because real hardware pulls different microcode/firmware. Bash branches (Install with archinstall-bash: moving towards systemd as the orchestrator #132, btrfspack) record timing as journal install milestones; their per-run package counts were not captured (the target unmounts before collection), but they install the same invariant root-image set as Install the target from a btrfs root image instead of pacstrapping it #113.
3. hegjon commented on Sep 4, 2026

   

   hegjon

   on Sep 4, 2026

   ContributorAuthor

   More actions

   QEMU install time, with 30 s of user input included

   The install-only numbers leave out the part a real user actually sits through: filling in the interactive installer. This adds a fixed 30 s of data entry to each candidate — a stand-in for a person answering the wizard, applied equally to all — so the totals read as end-to-end "how long from starting the installer to a booted, encrypted system."

   Same setup as the earlier QEMU comment: KVM on a Ryzen 9 9950X host, guest 16 vCPU / 16 GiB, Q35/OVMF, encrypted (LUKS) full-disk autoinstall, target a raw partition on a Samsung 990 PRO (cache=none). Builds are the same-day ISOs: quattro 2673c613d, #108 142f683a9, #113 0dcc9baf0, #132 8a9d209d9, #145 dbffaa6c6, btrfspack 6ac4cb48f. Three runs per candidate; install times are the installer's own record.

   Source: local filesystem (ISO on the host disk, cache=none)

   Candidate	Install (mean, range)	+ user input	Total
   #145 qcow2 restore	22.0 s (21.3–22.6)	30 s	52.0 s
   btrfspack	32.0 s (32–32)	30 s	62.0 s
   #113 btrfs image	40.1 s (39.5–40.9)	30 s	70.1 s
   #108 unsquashfs rootfs	41.2 s (39.7–43.3)	30 s	71.2 s
   #132 archinstall-bash	44.0 s (43–45)	30 s	74.0 s
   quattro (baseline)	53.6 s (52.6–54.6)	30 s	83.6 s

   Source: USB stick (DataTraveler 3.0, USB 3)

   Candidate	Install (mean, range)	+ user input	Total
   #108 unsquashfs rootfs	43.4 s (42.2–45.5)	30 s	73.4 s
   #145 qcow2 restore	56.2 s (55.1–56.9)	30 s	86.2 s
   #113 btrfs image	68.8 s (67.3–70.3)	30 s	98.8 s
   quattro (baseline)	69.2 s (68.9–69.5)	30 s	99.2 s
   btrfspack	87.0 s (87–87)	30 s	117.0 s
   #132 archinstall-bash	99.3 s (99–100)	30 s	129.3 s

   Reading it

   • The source medium changes who wins. From the host disk Speed up installs with compressed qcow2 restores and parallel finalization #145 is fastest by a wide margin (52 s total); from a USB stick Install from a prebuilt rootfs image instead of pacstrapping 925 packages #108 wins (73 s) and Speed up installs with compressed qcow2 restores and parallel finalization #145 falls to second, because the qcow2 restore no longer has a fast source to pull from.
   • The bash branches (Install with archinstall-bash: moving towards systemd as the orchestrator #132, btrfspack) are penalised on the slow medium. They verify the whole offline mirror before touching the disk; off a USB stick that read dominates (Install with archinstall-bash: moving towards systemd as the orchestrator #132 goes from 44 s to 99 s install), so they sink to the bottom of the USB table despite btrfspack being second-fastest from disk.
   • Install the target from a btrfs root image instead of pacstrapping it #113 tracks the baseline off a stick (68.8 vs 69.2 s) — its prebuilt image only helps as fast as the medium feeds it.
   • The 30 s is a fixed model, so it shifts every row equally and compresses the relative gaps: Speed up installs with compressed qcow2 restores and parallel finalization #145's 2.4x install-time edge over baseline from disk becomes 1.6x once user input is in the total.

   The 30 s is a stand-in, not a measurement; a manual pass through this installer landed in that range. Bash branches (#132, btrfspack) record timing as journal install milestones and their per-run package counts were not captured (the target unmounts before collection); they install the same invariant root-image set as #113.
4. emestee commented on Sep 28, 2026

   

   emestee

   on Sep 28, 2026

   More actions

   Hello,

   I have my own variant - would you be willing to test it as well? Not published yet.
5. hegjon commented on Sep 28, 2026

   

   hegjon

   on Sep 28, 2026

   ContributorAuthor

   More actions

   Go ahead and share your code, I plan to re-run next week with some other changes I want to tests
6. emirb commented on Oct 25, 2026

   

   emirb

   on Oct 25, 2026

   Contributor

   More actions

   We have landed so many changes, happy to get your feedback after we release 4.5 rc2! It was more testing and installs than I ever imagined, over 100 installs on real hardware and even more in QEMU. All code is from F1 branch (PR #216).