TL;DR
Get business pricing on networking and server gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
Tony Metzidis’s side-by-side test found WSL 3.0.2.0 outperformed WSL 2.6.3.0 across the measured kernel and Go compilation workloads. Results ranged from roughly 4% better syscall throughput to 61% higher memory-copy bandwidth, while a GoReleaser build finished about 4% faster; the results come from one test machine and do not establish a general performance gain for all users.
WSL 3.0.2.0 outperformed WSL 2.6.3.0 in a set of benchmarks published by developer Tony Metzidis, with gains varying by test from about 4% to 61%. The findings suggest that workloads involving memory bandwidth or task switching could benefit more than compute-heavy software builds, but the results reflect one test setup, not a broad performance guarantee for all Windows Subsystem for Linux users.
Metzidis compared WSL 2.6.3.0, running Linux kernel 6.6.87.2, with WSL 3.0.2.0, running kernel 6.18.40.1. In the low-level tests, basic getppid() throughput rose 3.98%, while scheduler and messaging benchmarks showed improvements of roughly 10% to 13%. The largest reported change was memory-copy bandwidth, which increased from 7.84 GB/s to 12.64 GB/s, a measured gain of 61.35% in that test.
The report also measured a GoReleaser compilation with an empty Go build cache and a primed module cache. Wall-clock time fell from 191.27 seconds to 183.80 seconds, a reduction of about 3.9%. CPU user time was about 3.2% lower, while time recorded in the kernel fell from 57.39 seconds to 48.22 seconds, or roughly 16%. The compiler test therefore showed a smaller overall improvement than the memory and scheduler microbenchmarks.
The test ran Alpine Linux 3.23.0 with Go 1.27.1 on an HP ProDesk 400 G4 Desktop Mini with an Intel Core i5-8500T processor and 16 GB of host memory. WSL was limited to two processors and 4 GB of memory. The host ran Windows 11 Pro with virtualization-based security active. Metzidis says the newer stack uses a newer guest kernel and a changed default virtualization runtime; the published measurements compare the bundled WSL versions and kernels, rather than isolating each change experimentally.
Where WSL 3 Shows Its Gains
The results matter most to developers who run Linux tools locally on Windows and whose workloads spend significant time moving data or coordinating many tasks. In the tests, memory-copy bandwidth increased by 61.35%, while context-switch and messaging measures improved by around 10% to 13%. Those changes could be relevant to memory-intensive applications or processes that exchange frequent messages, though the report did not directly benchmark production databases, container fleets, or complete microservice systems.
The compilation result offers a more restrained picture for everyday development. Although the reported kernel time fell by almost 16%, the total build was about 4% faster. That gap shows why a large microbenchmark gain should not be treated as an equivalent improvement in a full application: overall results depend on how much of a workload uses the part of the system that improved. Users whose work is dominated by CPU execution may see smaller gains than users limited by memory movement or kernel activity.
The figures are useful as an independently reported comparison, but not as a universal forecast. Hardware, processor allocation, memory limits, kernel configuration, software versions, and workload design can all affect results. Readers should treat the percentages as measurements from this configuration and test their own workloads before drawing conclusions about expected build times or application performance.
As an affiliate, we earn on qualifying purchases.
The Versions and Test Setup
The comparison covers two specific WSL releases: 2.6.3.0 and 3.0.2.0. Metzidis reports that the included Linux kernel moved from the 6.6 LTS branch, version 6.6.87.2, to kernel 6.18.40.1. Because the release comparison changes the WSL stack and guest kernel together, the report does not establish how much of each result came from a particular kernel change, virtualization-runtime change, or configuration setting.
For the benchmark, both environments used Alpine Linux 3.23.0 and the same stated Go version. The host was a six-core Intel system, but the WSL configuration assigned only two virtual CPUs and 4 GB of memory. These details are important: measurements from a constrained, specific machine can help explain behavior on that setup, but do not necessarily predict outcomes on systems with different processors, resource allocations, or software.
Metzidis points to the WSL 3 kernel command-line setting page_reporting.page_reporting_order=5 as a possible contributor to the memory result. He proposes that the setting’s page-reporting granularity may reduce overhead associated with dynamic memory reclamation. The benchmark reports a correlation between the newer stack and higher measured bandwidth; it does not separately test that setting to prove it caused the increase.
“The single largest jump is sequential memory throughput, climbing from 7.84 GB/s to 12.64 GB/s.”
— Tony Metzidis, benchmark report
As an affiliate, we earn on qualifying purchases.
Limits of the Published Comparison
The report describes one host computer, one resource configuration, and a limited set of benchmarks. It does not establish how often WSL 3 will be faster across the full range of developer applications, nor whether other hardware will show comparable percentages. The 5% to 60% framing should not be read as a measured range applying to every workload: the report’s specific results include a roughly 4% improvement in syscall throughput and a roughly 4% shorter Go build, as well as the 61.35% memory-bandwidth result.
It is also unclear how much each internal change contributed. The comparison pairs a new WSL release and kernel with the older versions, but does not test individual changes in isolation. Metzidis identifies page reporting and kernel or VMBus behavior as explanations for some results; these are the report author’s interpretations, not independently isolated causes in the benchmark data. The report does not provide results from multiple machines or repeated runs that would show variation between tests.
As an affiliate, we earn on qualifying purchases.
Testing on More Workloads
The immediate next step for readers is to compare the WSL versions using their own workloads and resource settings, especially if build duration or application responsiveness is the practical concern. To show how broadly the results apply, further reporting could test additional hardware, repeated runs, and different CPU and memory allocations, as well as representative development and server workloads.
More controlled comparisons could also separate the effects of the kernel update, virtualization runtime, and page-reporting configuration. Until such results are available, the benchmark supports a narrower conclusion: WSL 3 was faster in the tests Metzidis ran, with the size of the measured improvement dependent on the workload and test metric.
Windows Subsystem for Linux hardware
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Key Questions
How much faster was WSL 3 than WSL 2 in the report?
It varied by test. Metzidis measured 61.35% higher memory-copy bandwidth, scheduler and messaging improvements of roughly 10% to 13%, and a GoReleaser build that finished about 3.9% faster. These are results from his particular test setup, not a general guarantee.
Did the Go build finish 60% faster?
No. The GoReleaser build took 183.80 seconds on WSL 3, compared with 191.27 seconds on WSL 2, a reduction of about 3.9%. The result near 60% applied to the memory-copy bandwidth test, not the build.
What versions did the benchmark compare?
The report compared WSL 2.6.3.0 with Linux kernel 6.6.87.2 against WSL 3.0.2.0 with Linux kernel 6.18.40.1. Both were tested with Alpine Linux 3.23.0 in the stated configuration.
Will every WSL user see the same improvement?
The report does not establish that. It covers one computer, one allocation of two virtual CPUs and 4 GB of memory, and a limited benchmark set. Results may differ with other hardware, settings, and workloads.
Source: hn
Fall Picks
fall essentials
As an affiliate, we earn on qualifying purchases.
