Boot Loader Benchmarks: Measuring GRUB's Real Overhead and the Alternatives Fighting to Replace It
Most Linux engineers interact with GRUB twice: once when they install a distribution and configure it, and once when something goes wrong. Between those events, it sits at the start of every boot sequence, doing its job invisibly. That invisibility has insulated GRUB from the scrutiny its complexity deserves.
GRUB 2 is a remarkable piece of software in the literal sense: it contains a filesystem driver stack, a scripting language, a graphical menu renderer, network boot support, cryptographic libraries, and enough configuration surface area to fill a book. It also runs before the kernel, in an environment with no memory protection, no parallelism, and extremely limited error recovery. Every feature it carries is overhead paid on every boot.
This review benchmarks that overhead directly, compares it against systemd-boot and UEFI direct boot, and examines the decisions—technical and political—that keep GRUB installed on the majority of Linux systems despite faster options being available.
The Test Environment
We ran benchmarks across three hardware configurations to capture variation across consumer, workstation, and server contexts:
- System A: Consumer laptop, AMD Ryzen 7 7745HX, NVMe SSD, UEFI firmware (2023 vintage)
- System B: Workstation, Intel Core i9-13900K, NVMe RAID, UEFI firmware with Secure Boot
- System C: Server, AMD EPYC 7443, enterprise SAS SSD, UEFI with TPM 2.0
Each system ran identical kernel and initramfs configurations. Boot timing was captured using systemd-analyze with a consistent measurement methodology: five cold boots per configuration, discarding the first as a cache warmup artifact, averaging the remaining four. We measured time from power-on to userspace target completion—the point at which the system is fully operational.
Three boot loader configurations were tested on each system: GRUB 2.12 (current stable), systemd-boot 255 (as shipped with systemd), and direct UEFI kernel boot using the EFISTUB mechanism built into the Linux kernel itself.
Benchmark Results
System A (Consumer Laptop)
| Boot Loader | Firmware to Kernel | Kernel to Userspace | Total |
|---|---|---|---|
| GRUB 2.12 | 4.2s | 3.1s | 7.3s |
| systemd-boot | 1.8s | 3.1s | 4.9s |
| UEFI Direct (EFISTUB) | 1.1s | 3.1s | 4.2s |
System B (Workstation)
| Boot Loader | Firmware to Kernel | Kernel to Userspace | Total |
|---|---|---|---|
| GRUB 2.12 | 3.8s | 2.4s | 6.2s |
| systemd-boot | 1.5s | 2.4s | 3.9s |
| UEFI Direct (EFISTUB) | 0.9s | 2.4s | 3.3s |
System C (Server)
| Boot Loader | Firmware to Kernel | Kernel to Userspace | Total |
|---|---|---|---|
| GRUB 2.12 | 5.1s | 4.8s | 9.9s |
| systemd-boot | 2.3s | 4.8s | 7.1s |
| UEFI Direct (EFISTUB) | 1.4s | 4.8s | 6.2s |
The pattern is consistent across all three systems. The kernel-to-userspace phase is identical across boot loaders—as it should be, since the boot loader is no longer involved at that point. The entire difference lives in the pre-kernel phase, where GRUB's overhead ranges from 2.4 to 3.7 seconds compared to UEFI direct boot.
On the server, GRUB's pre-kernel time exceeded five seconds. For a system that may reboot infrequently, this is a minor irritant. For infrastructure where boot time affects recovery RTO, or for environments using network boot where every second costs money, it is a meaningful number.
Why Is GRUB This Slow?
The pre-kernel delay is not arbitrary. GRUB performs genuine work: it initializes its own runtime environment, loads and parses its configuration (which may involve reading from a filesystem), executes any scripting logic in grub.cfg, renders the boot menu (even briefly, before auto-selecting), and then loads the kernel and initramfs from disk. Each of these steps takes time.
The filesystem driver requirement is particularly significant. Because GRUB must read its configuration and the kernel image from disk before handing off to the kernel, it implements its own filesystem drivers for ext4, XFS, Btrfs, ZFS, and others. These are not the kernel's drivers—they are independent implementations maintained within GRUB itself. They work, but they add code complexity and initialization overhead.
Systemd-boot sidesteps this by operating exclusively from the EFI System Partition (ESP), which is always FAT32—a filesystem simple enough to implement trivially in UEFI context. It reads a minimal configuration file, presents a menu if configured to do so, and transfers control to the kernel. There is no scripting language, no network stack, no cryptographic library (Secure Boot verification is delegated to the UEFI firmware). The result is a boot loader that is genuinely minimal.
EFISTUB eliminates the boot loader layer entirely. The Linux kernel, when compiled with CONFIG_EFI_STUB, can be directly executed by UEFI firmware as an EFI application. The firmware reads the kernel, loads it, and jumps to its entry point. Boot loader overhead becomes zero.
Why Distributions Still Ship GRUB
Given these numbers, the persistence of GRUB as the default across most major distributions requires explanation.
Legacy BIOS support. GRUB is one of the few boot loaders that works on both BIOS and UEFI systems. Distributions that support hardware spanning multiple generations cannot simply drop GRUB without abandoning users on older machines. systemd-boot is UEFI-only by design.
Multi-boot complexity. GRUB's scripting model handles complex scenarios—multiple operating systems, multiple kernel versions with fallback logic, chainloading Windows—that simpler boot loaders handle less gracefully. For users dual-booting, GRUB's complexity is genuinely useful.
Encryption and early boot. GRUB supports LUKS2 full-disk encryption, allowing the boot partition itself to be encrypted. systemd-boot requires an unencrypted ESP. For security postures requiring encrypted /boot, GRUB remains the practical choice on most distributions.
Secure Boot integration. Secure Boot with GRUB requires a signed shim (as used by most major distributions) and a signed GRUB binary. The shim model is established and widely supported. systemd-boot also supports Secure Boot, but the signing infrastructure is less universally pre-configured in distribution tooling.
Installer complexity. Distribution installers have years of GRUB integration built in. Replacing the default boot loader requires rebuilding installer workflows, testing across hardware diversity, and handling edge cases that GRUB has accumulated solutions for over decades.
What the Alternatives Offer
systemd-boot is the most mature GRUB alternative for UEFI systems. It integrates cleanly with the systemd ecosystem, supports automatic entry discovery via the Boot Loader Specification, and is already the default on Fedora Silverblue, Pop!_OS, and several other distributions. Its configuration is straightforward enough that engineers rarely need to think about it after initial setup.
EFISTUB direct boot offers maximum simplicity and minimum overhead but requires managing kernel parameters through UEFI NVRAM variables or a wrapper like efibootmgr. It is appropriate for single-OS servers with stable kernel configurations and engineers comfortable with low-level UEFI tooling.
rEFInd occupies a middle ground—more capable than systemd-boot, less complex than GRUB—with strong hardware compatibility and a graphical interface that some users prefer. It remains a niche choice but is actively maintained.
Distribution Behavior
Fedora has been the most aggressive in moving away from GRUB: Fedora Workstation switched to systemd-boot as the default installer choice starting with Fedora 37 on compatible hardware. Ubuntu continues to default to GRUB across all variants. Arch Linux supports both and leaves the choice to the user, with documentation for each path. Debian ships GRUB as default with no installer-level alternative presented.
NixOS is uniquely positioned: its declarative configuration model makes switching boot loaders a single-line change, and the community maintains well-tested configurations for GRUB, systemd-boot, and EFISTUB. It is the easiest environment in which to experimentally compare boot loader behavior.
Conclusion
GRUB is not a bad boot loader. It is a capable, battle-tested, extraordinarily flexible piece of software that solves problems most users do not have. Its overhead is real, measurable, and unnecessary for a large fraction of the systems it runs on—particularly servers with known hardware, single-OS configurations, and modern UEFI firmware.
For fresh infrastructure deployments on UEFI hardware, systemd-boot deserves serious consideration as the default. For environments where boot time is operationally significant, EFISTUB is worth the additional configuration investment. GRUB earns its place on legacy hardware, complex multi-boot configurations, and encrypted boot partitions—but defaulting to it everywhere because it has always been the default is a choice worth revisiting.
