Performance

OneShader compiles a shader about 2.4 times faster than DXC when both run as native processes, and about 14 times slower when it runs as an ordinary .NET process that has to start the runtime and JIT-compile the compiler first. Both are measured below, on the same 68 entry points, with the compiler's SPIR-V compared against DXC's SPIR-V. This page prints all of it: the tables, the losses and the method.

Every number comes from the files in bench/results/, measured on one workstation (see Method). Treat them as local measurements, not promises for your hardware.

Results at a glance

One shader compile per process, for each of the 68 (file, entry point) pairs the repository's execution-parity cases compile (25 2D-renderer, 24 3D, 11 compute, 8 language-feature entry points). DXC is the released binary run with -spirv; its default optimization. OneShader is a small command-line wrapper around ShaderCompiler.CompileFile, built three ways: as a NativeAOT binary, as a framework-dependent ReadyToRun build, and as a plain framework-dependent (JIT) build. Time is wall-clock from creating the process to its exit, with the blob written to disk. The ratio is DXC's time divided by ours per entry point, summarized by the geometric mean; a time within 5% of DXC's is a tie.

The chart is drawn from the results file by bench/make-report.py.

"Warm" is the median of 15 repeated runs per entry point; "cold" is the first run of each entry point right after the corpus was written to a fresh directory.

The losses

• Started as a .NET process, OneShader is slower than DXC on every entry point. The JIT build is 14.3× slower warm (113 ms median per entry point against DXC's 7.6 ms) and 12.9× slower cold; ReadyToRun is 6.1× and 5.3× slower (48 ms median). Almost all of that is starting the runtime and compiling or loading the compiler's code, not compiling the shader: the same compile inside a running process takes 0.34 ms at the median (in-process). The NativeAOT build is the one that wins, so a command-line tool that compiles shaders should ship NativeAOT; the MSBuild task runs inside the build's own long-lived .NET process, where the runtime start-up is paid once per build, not once per shader (that case, the first compile in a fresh process, is not measured here).
• The SPIR-V is larger than DXC's with debug names on, which is the default. 57 of 68 entry points are larger, 46,620 words against DXC's 44,126 (+5.7%); the worst are lang/sizeof_static.hlsl:CSMain (+90%), 3d/skinned.hlsl:VSMain (+60%) and 3d/stage_io.hlsl:VSMain (+36%). With names off (CompileOptions.KeepNames = false) the total is 40,258 words, 8.8% below DXC, with 61 entry points smaller and 7 larger. DXC emits no names unless asked, so the second comparison is the like-for-like one; the first is what the compiler gives you by default (table).
• The optimizer is the largest cost of a compile. With it off, SPIR-V takes 0.13 ms at the median instead of 0.34 ms (2.5× less); the worst file, 3d/bloom_downsample.hlsl, takes 1.18 ms with the optimizer and 0.22 ms without (5.5×). That is the price of the smaller output; see the in-process table.
• MSL and WGSL are not on the chart. DXC has no such outputs, so there is nothing to compare; their in-process times are in the table. They also refuse some corpus shaders, which are left out of those columns: MSL refuses compute/append_consume.hlsl; WGSL refuses that file, 3d/stage_io.hlsl and lang/resource_arrays.hlsl (the diagnostics are in bench/results/inproc/).
• No in-process comparison with DXC. DXC is timed as a process only. Its in-process cost is not measured, so the in-process numbers below stand alone.

In-process compile time

ShaderCompiler.Compile called on the source text in a warm process, every entry point of a file in one call, SPIR-V with the default optimizer unless the column says otherwise. BenchmarkDotNet 0.15.8 with the memory diagnoser, in-process toolchain, 3 warm-up and 12 measured iterations of at least 150 ms each (10 to 12 kept after outlier removal); the mean in milliseconds, then the standard deviation in brackets, and the managed allocation per call in KiB. Includes (3d/brdf.hlsli) are read from disk during the compile; the shader text is read once beforehand.

Over the 41 files: the median file compiles in 0.34 ms and allocates 0.85 MiB; the slowest is 2d/renderer/ui.hlsl at 2.0 ms and 4.2 MiB. MSL and WGSL cost about 3 to 5% more than SPIR-V. The first row, 2d/blit.hlsl with SPIR-V, was the first benchmark the process ran and shows it (a standard deviation of 34% of its mean; the same file with MSL, run later, takes 0.12 ms): read that one cell as a warm-up artifact.

"refused" marks a file the target does not support; it is left out rather than timed as a failure.

Process time per entry point

Median of 15 warm runs in milliseconds, with the fastest and slowest run in brackets, for each entry point. "vs DXC" is DXC's median divided by the OneShader median.

Cold runs

The first run of each entry point after the corpus was copied to a fresh directory, one sample each (no spread to show). The page cache was not dropped (that needs privileges the benchmark does not use), so "cold" here means first run, not a cold disk: the JIT and ReadyToRun builds pay for loading and compiling code on every process start, and every process, warm or cold, is a new process.

Output size

SPIR-V words (a word is 4 bytes) for the same entry points, from the NativeAOT build (the other two builds write identical bytes). "Without debug names" is the same compile with KeepNames = false. DXC is run with its defaults, which emit no names.

Method

• Entry points. Every (file, entry point, stage) that the execution-parity cases in corpus/cases/*.case compile, without duplicates: 68 entry points in 41 files (a file's entry points are compiled together in the in-process benchmark and one per process in the process benchmark). Includes and the cases' preprocessor definitions are passed to both compilers.
• DXC. The released Linux x64 binary v1.9.2609 (libdxcompiler 1.9.2609.5), pinned with its checksum in tools/oracles.env, run as dxc -spirv -fspv-target-env=vulkan1.2 -HV 2021 -T <vs|ps|cs>_6_0 -E <entry> -I <dir> -Fo <out> <file>; no optimization flags (so its default). It is used only as a black-box binary.
• OneShader. bench/OneShader.Bench.Cli (oshc): ShaderCompiler.CompileFile with one entry point, SPIR-V, default options (optimizer on, debug names kept), writes the blob. Published three ways: dotnet publish -r linux-x64 -p:PublishAot=true; --self-contained false -p:PublishReadyToRun=true; and --self-contained false (JIT, with the runtime's default tiered compilation). The framework-dependent builds run through their oshc launcher on the machine's .NET runtime.
• Process timing. The driver creates the process, waits for it to exit and takes the elapsed time on a monotonic clock; standard output and error are captured and discarded. Warm rounds run the tools interleaved (DXC, then each OneShader build) for each entry point, so a drift in machine speed affects all of them alike. Each round visits all 68 entry points; there are 15 rounds.
• In-process timing. BenchmarkDotNet as described above. The in-process toolchain is used because the repository's build output layout does not suit BenchmarkDotNet's generated projects; the compiler runs in the benchmark's own process.
• Size. Bytes written by each compiler on the cold pass, divided by 4.
• Reproduce. bench/run.sh (optionally --warm N, --skip-inproc, --skip-process, --out DIR) builds, publishes the three builds, fetches the pinned DXC with tools/fetch-oracles.sh, runs both benchmarks, writes bench/results/ and regenerates the tables on this page and the charts in docs/img/. It needs the .NET SDK from global.json, Python 3, and a C toolchain with zlib for NativeAOT. bench/OneShader.Bench list prints the 68 entry points.

Machine and load

• Hardware and software. AMD Ryzen 9 7950X3D (16 cores, 32 logical), 125 GiB RAM, Linux Mint 22.3, .NET SDK 10.0.402 with runtime 10.0.13, DXC v1.9.2609, BenchmarkDotNet 0.15.8. Default runtime settings (no AVX-512 switches, tiered compilation on, workstation non-concurrent GC in the benchmark process).
• A shared machine, run under a lock. The run was the only benchmark on the machine: it held the machine's benchmark lock for the whole run and no other project's heavy job overlapped. Load averages (1 minute) were sampled every 5 seconds by the benchmark itself: at the start 1.24 (1-minute), 1.44 (5-minute), 1.49 (15-minute); during the process timing 1.03 to 1.24 over 41 samples; during the in-process benchmark 1.02 to 1.42 over 95 samples; at the end of the process timing 1.13, 1.26 and 1.41, and 1.09, 1.14 and 1.28 when the whole run finished. The remaining load of about 1 is background work on the machine that the benchmark did not control.
• One run. The published numbers are from a single full run (2026-10-25). The spread between repeated warm runs is shown in the process table: a NativeAOT process lasts about 3 ms, so its slowest run is typically 1.5× its entry point's median (at most 2.1×), while DXC's slowest run is typically 1.15× its median (at most 1.5×). The ratios use medians. In-process results are kept as BenchmarkDotNet's *-report-full.json in bench/results/inproc/, with the file list per target (params-*.tsv) the report uses to restore the file names BenchmarkDotNet shortens.
• Not measured. Memory use of either compiler (the NativeAOT binary is 2.9 MB; DXC is a 0.76 MB launcher plus a 31.8 MB compiler library); Windows or macOS; ARM64; multi-threaded or batch compiles (DXC and OneShader are each run one entry point at a time); compile time against other shader compilers.