WSL3 Performance: A 5-60% Boost Over WSL2 Depending on Workload

By Tony Metzidis | AI, Cloud, & Engineering Leadership Published: October 7, 2026 $\cdot$ 4 min read $\cdot$ #Wsl #Wsl2 #Wsl3 #Benchmarks

With the introduction of the WSL 3.x stack, Microsoft has updated the default virtualization runtime and upgraded the guest kernel from the 6.6 LTS branch to 6.18.

While official marketing often highlights generalized speed increases, these bullet points rarely provide a clear picture of how developer-specific workloads are affected. To uncover the actual technical shifts, I conducted a side-by-side comparison between WSL 2.6.3.0 (Kernel 6.6.87.2) and WSL 3.0.2.0 (Kernel 6.18.40.1).

The following data examines kernel primitives, memory throughput, and a practical Go compilation scenario.

---

🛠️ The Test Environment

To ensure the results were reproducible and isolated, I utilized an Alpine Linux 3.23.0 root filesystem (minirootfs) running Go 1.27.1.

Hardware & Software Specifications

• Host OS: Windows 11 Pro (Build 26200.9550, VBS enabled)
• Host Machine: HP ProDesk 400 G4 Desktop Mini
• CPU: Intel Core i5-8500T (6C/6T Coffee Lake @ 2.10 GHz)
• RAM: 16 GB DDR4
• Guest OS: Alpine Linux 3.23.0 (x86_64)
• Guest Kernels: 6.6.87.2 (WSL2) vs 6.18.40.1 (WSL3)

Resource Configuration

The following settings were applied via the .wslconfig file:

[wsl2]
processors=2        # Pinned to 2 vCPUs
memory=4GB
networkingMode=nat
firewall=true

---

📉 Low-Level Kernel Microbenchmarks

Using perf bench, I isolated raw IPC throughput, scheduler latency, and memory bandwidth to remove user-space noise.

Analysis of Kernel Improvements

The Memory Breakthrough: The most staggering gain is the +61.35% increase in sequential memory throughput. This is largely attributed to the kernel command line parameter: page_reporting.page_reporting_order=5. By increasing the granularity of page reporting, the system reduces the frequency of hypervisor traps and the overhead of page-table walking during Hyper-V dynamic memory reclamation.

• Scheduler IPC Latency ($\approx -11\%$): Improvements in the upstream 6.18 scheduler, combined with optimized Hyper-V VMBus synthetic interrupt handling, have reduced the "wake penalty" when tasks bounce between the two pinned vCPUs.
• Syscall Transitions ($\approx -3.8\%$): The modest gain in getppid suggests that ring transitions on 8th-Gen Intel chips are limited by hardware architecture, leaving little room for software-only optimization.

---

🚀 Real-World Workload: GoReleaser Compilation

To see if these micro-gains translate to actual development, I compiled the GoReleaser codebase using go build -a -o /dev/null. I ensured a clean state by running go clean -cache while keeping the module cache primed.

Understanding the Runtime Split

While the total wall-clock time only improved by $\approx 4\%$, the internal breakdown reveals a different story:

1. Kernel Overhead Collapse: The sys time dropped by nearly 16%. Because the compiler relies heavily on mmap, futex, and openat calls to manage the package graph, the improved slab caching and lower trap overhead in kernel 6.18 provided a significant win.
2. The Hardware Ceiling: The reason the total time didn't drop further is that compilation is primarily a user-space compute task (Lexing, AST, SSA optimization). Since the VM is capped at two 2.10 GHz cores, the CPU clock speed becomes the primary bottleneck, not the kernel.

---

🏁 Final Takeaways

Upgrading to WSL 3.x is highly recommended, but the perceived benefit depends on your specific usage:

• ✅ High-Churn & Memory-Heavy Systems: If you run in-memory databases (e.g., Redis), dense container environments, or microservices using Unix domain sockets, you will see immediate, massive benefits.
• ⚠️ Compute-Bound Toolchains: If your primary bottleneck is raw CPU execution (like heavy compilation), WSL 3.x will reduce the time spent in the kernel, but your total build time will still be limited by your physical hardware.

Upgrade Checklist

• Update WSL to version 3.0.2.0 or higher.
• Verify kernel version is 6.18.x.
• Check .wslconfig for optimal vCPU pinning.

Related Reading:

• The "Security Tax": Reclaiming 30% Performance in WSL 2
• Isolated Sandboxed WSL Environments with Debian Slim
• Taming GCE Memory Tax on Small Instances