A new Phoronix benchmark blitz reveals that running Ubuntu 24.04 inside WSL2 on Windows 11 25H2 extracts a 13% performance penalty compared to bare-metal Ubuntu on the same hardware. The gap widens sharply for I/O-heavy work, putting developers on notice that while WSL2 remains a capable daily driver, it is no drop-in replacement for native Linux in throughput‑critical pipelines.

Phoronix’s test suite spanned more than 50 real‑world workloads on an AMD Ryzen 9 9950X3D machine with a Crucial T705 PCIe Gen 5 NVMe SSD and 32 GB of RAM. Ubuntu 24.04 under WSL2 / Windows 11 Pro 25H2 (Release Preview) delivered a geometric mean of 87% of the performance of Ubuntu 24.04.3 LTS installed on the same metal. That 13% aggregate shortfall is the headline number, but the real story lives in the workload‑dependent spread: compute‑bound tasks often ran neck‑and‑neck with native Linux, while file‑system‑intensive operations bled double‑digit losses.

Testbed and Methodology

Phoronix’s methodology deliberately isolates OS and subsystem overhead by holding hardware constant across both environments. The CPU is an AMD Ryzen 9 9950X3D, the storage is a 1 TB Crucial T705 NVMe SSD, and memory was fixed at 32 GB. The Windows stack consisted of Windows 11 Pro 25H2 (a preview build) hosting Ubuntu 24.04 via WSL2; the bare‑metal comparison ran Ubuntu 24.04.3 LTS directly. All environments were left at their out‑of‑the‑box defaults—no manual tuning, no power‑plan tweaks—to reflect the experience of developers who lack the time or permission to fine‑tune their machines.

The benchmark suite mixed real‑world applications (LLVM, Godot, FFmpeg compilations) with database stress tests (SQLite), compression (7‑Zip), cryptographic kernels (OpenSSL), and dozens of other microbenchmarks. Results were aggregated into a geometric mean that gives equal weight to each test, avoiding domination by any single workload. This design makes the aggregate figure a honest, if approximate, yardstick of overall throughput.

Headline Findings: 87% Geomean

Across the entire suite, WSL2’s Ubuntu 24.04 scored 0.87× the performance of native Ubuntu 24.04.3. The 13% penalty is larger than some earlier WSL2‑vs‑native comparisons that landed in the mid‑90% range, though those earlier tests ran on different hardware, older kernels, and narrower test mixes. Phoronix’s own previous rounds have occasionally shown WSL2 reaching 95% of bare‑metal speed, but the current 87% figure is specific to this Ryzen 9 9950X3D / Ubuntu 24.04 / Windows 11 25H2 combination.

Breaking the results down:
- CPU‑bound workloads (pure math kernels, many cryptographic operations, single‑threaded scripting) often performed within a few percent of native. In a handful of light PHP and Python tests, WSL2 actually edged ahead of bare‑metal Ubuntu—likely a quirk of scheduler interaction between the Windows host and the WSL2 Linux kernel.
- I/O‑heavy workloads were the performance killers. SQLite, compilation tasks with heavy file access, and any operation involving numerous small file reads or writes showed the steepest drop‑offs. In some file‑system‑intensive tests, WSL2 lost 20% or more compared to native ext4 performance.
- Mixed workloads fell between these extremes, dragging the geomean down to 87%.

Why WSL2 Loses Ground: Technical Breakdown

The performance delta isn’t caused by a single bottleneck; it’s the sum of several architectural differences between Windows‑hosted WSL2 and bare‑metal Linux.

1. Filesystem and I/O Arbitration

WSL2 runs Linux inside a lightweight Hyper‑V virtual machine. When Linux processes access files on the native WSL2 ext4 volume (e.g., /home), performance is decent. But cross‑filesystem operations—accessing Windows drives mounted under /mnt/c, for instance—hit multiple layers of translation: the 9P protocol, Windows filesystem filters, and antivirus scanners. Even though WSL2 has improved cross‑OS file access significantly since its debut, the overhead remains substantial for workloads that generate a storm of small I/O requests. Compilation monorepos, npm installs, and database benchmarks like SQLite directly expose this penalty. Phoronix’s data show that simply placing a project on the WSL2 VM’s native ext4 filesystem can claw back much of the I/O deficit.

2. Virtualization and Context‑Switch Costs

WSL2 is not a thin syscall translator like its predecessor WSL1; it boots a genuine Linux kernel in a managed VM. That kernel brings full compatibility with Linux containers, eBPF, and kernel modules, but it also introduces VM‑exit overhead for I/O, interrupt handling, and device emulation. In CPU‑bound tasks the overhead is negligible, but in code paths that depend on rapid context switches—think heavily threaded builds or network‑intensive services—the aggregate cost can become measurable.

3. Toolchain and Runtime Divergence

Phoronix’s benchmarks used native Linux binaries wherever possible, but subtle toolchain differences can still affect results. Even when the same source code is compiled, Windows‑side statically linked binaries may exhibit different instruction sequences than their Linux counterparts; conversely, when the identical Linux binary runs in both environments, the remaining variation is down to kernel scheduling, memory management, and I/O paths. In these tests, OpenSSL on WSL2 actually ran faster than on native Linux in certain modes, showing that the interplay between Windows’ host scheduler and the WSL2 kernel can occasionally yield surprise wins for specific microbenchmarks.

4. System Services and Security Stack

A stock Windows 11 Pro install carries a heavier background‑service load than a minimal Ubuntu Server setup. Windows Defender’s real‑time scanning, telemetry agents, and other system services compete for CPU cycles and, more critically, inject latency into file I/O. WSL2’s VM environment partially insulates Linux processes, but the host’s security stack still intercepts every access to files on Windows volumes. In enterprise settings, third‑party endpoint protection can amplify these latencies dramatically.

What the Numbers Mean for Developers

Phoronix’s work is a pragmatic wake‑up call for anyone using WSL2 as a primary development environment. The convenience of having a full Linux toolchain inside Windows is undeniable, but teams must approach it with eyes wide open.

Convenience‑First Workflows

For interactive development—editing code, running quick build loops, testing small changes, and leveraging Linux‑only tools—WSL2 remains excellent. Its integration with Windows IDEs, native Docker Desktop support, and zero‑reboot workflow make it far more pleasant than dual‑booting. In these scenarios, a 13% compile‑time penalty on a five‑second build adds just over half a second, an overhead most developers will trade for the seamless experience.

Throughput‑Critical Pipelines

The picture changes for CI servers, nightly builds, database performance testing, or any job where absolute throughput governs whether deadlines slip. A 13% slower geomean can mean missing a nightly regression window or pushing commits an hour later. For these workloads, native Linux—or cloud‑native Linux runners—should be the default choice. If enterprise policy mandates Windows on developer laptops, a hybrid model works best: interactive work in WSL2, heavy lifting on dedicated Linux machines or VMs with direct disk access.

Practical Compromise

Many teams can adopt a tiered strategy:
- WSL2 for editing, debugging, quick iterations, and most container‑based microservice development.
- Native Linux (bare metal or a VM with PCIe passthrough) for long‑running compilation farms, AI/ML training jobs, and database benchmarking.
- Inside WSL2, keep source trees on the VM’s native ext4 filesystem (not on /mnt/c) to avoid cross‑filesystem penalties. Exclude those directories from real‑time antivirus scanning where policy permits.

When WSL2 Shines

Despite the measured shortfall, WSL2 retains distinct advantages that no benchmark suite can capture:
- Real Linux kernel: Running Docker, Kubernetes, eBPF, and other cutting‑edge Linux features without a separate machine or dual‑boot.
- Seamless tooling: VS Code’s Remote‑WSL extension, Visual Studio, and IntelliJ all connect directly to the WSL2 environment, giving developers the best of both worlds.
- Rapid onboarding: New team members can be productive within minutes on a company‑provisioned Windows laptop, with no need to repartition or manage a separate Linux image.
- Low‑overhead snapshot integration: WSL2’s VM can be quickly stopped and restarted, and its filesystem can be backed up via Windows tools.

For the vast majority of individual developers, WSL2 is “good enough.” Phoronix’s own conclusion echoes this: the subsystem is practical and productive, even if it isn’t performance‑equivalent in every corner case.

Optimizing WSL2 for Heavy Workloads

If you must run demanding Linux workloads on a Windows machine, several tuning steps can narrow the WSL2‑native gap:

  1. Project placement: Store code, build artifacts, and databases inside the WSL2 VM’s ext4 volume (e.g., ~/projects). Avoid accessing Windows drives for any write‑heavy or file‑intensive operation.
  2. Antivirus exceptions: Work with your IT security team to exclude WSL2 project directories from real‑time scanning. Document the exceptions and limit them to the specific paths that need protection.
  3. Resource allocation: WSL2 respects .wslconfig settings for memory and CPU limits. For compilation‑heavy tasks, ensure the VM has sufficient memory (avoid aggressive ballooning) and all CPU cores are available.
  4. Enable nested virtualization when needed: If you run Docker inside WSL2, confirm that nested virtualization is enabled and that Hyper‑V’s hypervisor supports the workloads.
  5. Measure your own workload: Phoronix’s 87% is a composite. Run a representative subset of your own build or test suite inside WSL2 and on a native Linux reference machine. The delta for your specific codebase will be far more actionable than any generic benchmark.

Risks, Caveats, and What to Watch

Phoronix’s results are a snapshot of one high‑end desktop platform at a single point in time. Several variables can shift the performance delta:

  • Hardware diversity: The Ryzen 9 9950X3D pair with a Gen 5 NVMe drive is scorching fast. Slower storage, hybrid Intel CPUs with P‑ and E‑cores, or different firmware settings may produce different relative outcomes.
  • WSL2 kernel updates: Microsoft regularly updates the WSL2 Linux kernel (often aligning with upstream LTS releases). Each kernel refresh can bring filesystem improvements, memory management tweaks, or scheduler bug fixes that alter the overhead profile.
  • Windows Defender and enterprise AV: In corporate environments, the performance impact of endpoint security agents can easily dwarf the raw WSL2 overhead. Teams should profile WSL2 on their managed images, not on a clean Windows install.
  • Binary parity: When feasible, use the identical Linux binaries (same compiler, same flags) in both environments to ensure that toolchain differences do not pollute the comparison.

Verify the exact Phoronix test page for the most current data. At the time of writing, the WSL2‑specific article explicitly lists the AMD Ryzen 9 9950X3D and Crucial T705 NVMe drive as the test platform.

Cross‑Check and Verification

Phoronix’s findings are corroborated by both Microsoft’s own communication about 25H2 and independent reporting:
- Microsoft describes Windows 11 25H2 as an enablement package delivered via a cumulative update on the servicing branch. This means the 2025 Update does not introduce sweeping kernel or scheduler changes—consistent with Phoronix’s choice to benchmark WSL2 behavior rather than host‑side improvements.
- Outlets such as Tom’s Hardware and TechRadar have republished and summarized the same results, repeating the core takeaways: no meaningful 25H2‑specific gains versus 24H2, and Linux retaining a lead in many CPU‑bound workloads.

Previous WSL2 benchmarks have occasionally shown smaller penalties (mid‑90% range), underscoring that the WSL2‑to‑native delta moves with kernel updates, workload mix, and platform hardware. The 87% figure should be treated as a precise measurement for the tested configuration, not an eternal ceiling.

Conclusion

Phoronix’s latest round of testing paints a clear, pragmatic picture: WSL2 on Windows 11 25H2 is a highly usable, low‑friction Linux environment that extracts a measurable—but often tolerable—performance cost. The 13% geomean penalty is most acute in I/O‑bound tasks, where the virtualization and filesystem translation layers exact their toll. For interactive development, scripting, and light testing, WSL2 remains the most productive way to run Linux on a Windows machine. For heavy‑duty CI, database benchmarking, or any workflow where every second of build time counts, native Linux still reigns.

Developers and IT leaders should use these findings to inform a workload‑driven strategy: lean on WSL2 for day‑to‑day convenience, offload loud tasks to native Linux runners, and continuously validate performance as Microsoft rolls out kernel and WSL updates. A single pilot benchmark on your own codebase will tell you more than any industry‑average geomean.

Source: Phoronix https://www.phoronix.com/review/windows-11-wsl2-2025/