Command-line applications have a different performance profile from long-running web services.
A web API may stay alive for hours or days, allowing the .NET runtime to spend time optimizing execution after startup. A CLI tool may run for only a few seconds, process some input, produce output, and exit.
That makes startup time and application footprint much more important.
.NET NativeAOT provides a way to compile an application ahead of time into native code instead of relying on the traditional JIT-based execution model.
But NativeAOT is not automatically faster for every workload.
A useful engineering question is:
When does NativeAOT provide a measurable advantage over a conventional JIT-based .NET CLI application?
The answer depends on startup cost, workload duration, binary size, memory usage, throughput, dependencies, reflection requirements, and deployment environment.
This article presents a practical methodology for benchmarking NativeAOT CLI tools against conventional .NET applications without confusing startup improvements with overall application performance.
What NativeAOT Changes
A conventional .NET application typically follows a runtime model similar to:
Application
|
v
.NET runtime
|
v
JIT compilation
|
v
Machine code
|
v
Execution
NativeAOT changes the model:
Application
|
v
AOT compilation
|
v
Native executable
|
v
Operating system
|
v
Execution
The important difference is when code generation happens.
With JIT-based execution, portions of code can be compiled at runtime.
With NativeAOT, application code is compiled ahead of time.
This can reduce startup work, but it also introduces additional build-time constraints.
Why CLI Applications Are Interesting
Consider a CLI command that executes for 300 milliseconds.
The total execution time may look like:
Startup 100 ms
Processing 150 ms
Shutdown 50 ms
-------------------
Total 300 ms
If startup is reduced significantly, the total runtime can change substantially.
Now consider a server application:
Startup 500 ms
Processing 12 hours
The startup difference is almost irrelevant to the application's lifetime.
This is why NativeAOT benchmarking is particularly interesting for:
JIT-Based and NativeAOT Builds Are Different Deployment Models
A fair benchmark should compare equivalent applications.
For example:
CLI source
|
+---- Standard .NET build
|
+---- NativeAOT publish
Both versions should:
Do not compare a highly optimized NativeAOT implementation with a different JIT implementation.
The benchmark is about the deployment model, not application design.
Create a Representative CLI Workload
Start with a simple application that performs measurable work.
For example, a JSON-processing CLI might:
Read a file.
Deserialize records.
Transform the data.
Calculate summary information.
Serialize the result.
Exit.
A simplified implementation could look like:
using System.Text.Json;
var inputPath = args.Length > 0
? args[0]
: "input.json";
await using var stream =
File.OpenRead(inputPath);
var records =
await JsonSerializer.DeserializeAsync<List<Record>>(stream)
?? [];
var total = records.Sum(x => x.Amount);
Console.WriteLine(
$"Records: {records.Count}");
Console.WriteLine(
$"Total: {total:N2}");
public sealed class Record
{
public int Id { get; set; }
public decimal Amount { get; set; }
}
The application should do enough work to make the benchmark meaningful.
Publish the Standard Version
Build the conventional application using the normal release configuration:
dotnet publish \
-c Release \
-r win-x64 \
--self-contained true
The exact runtime identifier should match the machine used for testing.
Self-contained and framework-dependent deployments should not be mixed in the same comparison because they represent different deployment characteristics.
Publish the NativeAOT Version
NativeAOT can be enabled in the project configuration.
A simplified project configuration looks like:
<PropertyGroup>
<PublishAot>true</PublishAot>
</PropertyGroup>
Then publish for the target runtime:
dotnet publish \
-c Release \
-r win-x64
The resulting output is intended to run as a native executable.
The important point is that the NativeAOT build should use the same source code and release configuration as the baseline unless the benchmark explicitly investigates a different configuration.
NativeAOT Has Compatibility Constraints
NativeAOT is not simply a switch that makes every .NET application faster.
Some applications depend heavily on runtime behaviors such as:
Modern .NET libraries increasingly provide AOT-friendly patterns, but an application should be tested rather than assumed to be compatible.
This matters when designing a benchmark.
If the JIT version works but the NativeAOT version requires substantial architectural changes, you are no longer measuring only the runtime deployment model.
Measure Startup Separately
One of the biggest mistakes in CLI benchmarking is measuring only total execution time.
Measure startup independently.
A useful conceptual model is:
Total Time
=
Startup
+
Application Work
+
Shutdown
For a short-running CLI, startup can represent a large percentage of total execution time.
A benchmark should therefore capture:
Process launch
|
v
Application ready
|
v
Work begins
|
v
Application exits
Operating-system process timing tools can be used for coarse end-to-end measurements.
For more detailed investigation, application-level instrumentation can record when meaningful application work begins.
Warm Runs Can Mislead CLI Benchmarks
A JIT-based application can behave differently between its first and subsequent executions.
For example:
Run 1
Startup + JIT + application work
Run 2
Startup + cached operating-system state + application work
If you benchmark only warm runs, you may hide part of the startup cost that matters to users running a CLI command once.
Run both:
Cold-start scenario
Warm-start scenario
and clearly report which one each measurement represents.
Benchmark Repeated CLI Invocations
A useful test is to run each executable repeatedly.
For example:
Standard .NET
Run 1
Run 2
Run 3
...
Run 30
NativeAOT
Run 1
Run 2
Run 3
...
Run 30
Then calculate:
Median
p95
Minimum
Maximum
Standard deviation
For short-lived processes, the median is often more useful than a single measurement.
A single execution can be affected by:
File-system state
Antivirus scanning
CPU scheduling
Background processes
Operating-system caching
Thermal conditions
Measure Memory Usage
Startup time is only one part of the comparison.
Measure process memory as well.
Useful metrics include:
Working set
Private memory
Peak memory
Managed allocations
Do not confuse process working set with managed heap size.
A native executable can have different memory behavior even when the managed allocation profile is similar.
For a CLI tool running hundreds or thousands of times in automation, small differences can become operationally important.
Measure Binary and Deployment Size
NativeAOT can change the shape of the deployment artifact.
Measure:
Executable size
Total publish directory size
Number of files
Required runtime components
For example:
| Metric | JIT-Based | NativeAOT |
|---|
| Executable size | Measure | Measure |
| Publish directory | Measure | Measure |
| Startup time | Measure | Measure |
| Peak memory | Measure | Measure |
| Processing time | Measure | Measure |
| Total execution time | Measure | Measure |
Do not assume that NativeAOT always produces a smaller artifact.
The correct result depends on application dependencies and publishing configuration.
Separate Startup From Throughput
Suppose the benchmark produces these measurements:
JIT
Startup: 80 ms
Processing: 120 ms
Total: 200 ms
NativeAOT
Startup: 25 ms
Processing: 125 ms
Total: 150 ms
NativeAOT improves total execution time primarily because startup is lower.
That is different from saying:
NativeAOT makes the algorithm 50% faster.
It does not.
The processing phase actually became slightly slower in this hypothetical example.
This distinction is important when presenting benchmark results.
Measure CPU Usage
NativeAOT can change CPU behavior, but the direction is workload-dependent.
Measure CPU usage during:
Startup
Processing
Shutdown
For example:
CPU Time
|
+-- Process startup
+-- JIT/AOT-related execution
+-- Application processing
For short-running processes, percentage-based CPU measurements can be misleading because the process may terminate before sampling tools capture enough information.
CPU time is often more useful when available.
Avoid Overfitting to a Microbenchmark
A CLI tool that calculates a small mathematical expression may not represent a real application.
For example:
var result = 10 * 20;
is not an interesting NativeAOT workload.
Instead, use workloads that represent actual CLI behavior:
JSON processing
File processing
Parsing
Code generation
Database interaction
Archive processing
Batch transformation
The benchmark should answer a real deployment question.
A Useful Benchmark Matrix
A practical test matrix might look like this:
| Workload | Input Size | Runs | JIT | NativeAOT |
|---|
| JSON parsing | 100 KB | 30 | Measure | Measure |
| JSON parsing | 10 MB | 30 | Measure | Measure |
| File processing | 10 MB | 30 | Measure | Measure |
| File processing | 500 MB | 10 | Measure | Measure |
| Code generation | Small | 30 | Measure | Measure |
| Code generation | Large | 30 | Measure | Measure |
The exact workloads should reflect the application's purpose.
Use BenchmarkDotNet Carefully
BenchmarkDotNet is useful for controlled .NET performance experiments, but process-startup benchmarking requires care.
A microbenchmark typically keeps one process alive and invokes methods repeatedly.
That is useful for measuring:
Method execution
Allocations
CPU performance
It is not automatically equivalent to:
Launching CLI process
Starting runtime
Loading application
Performing work
Exiting process
For CLI startup benchmarking, measure the executable as a process.
For algorithm benchmarking, BenchmarkDotNet can be used separately.
A strong performance study can therefore have two layers:
Layer 1
Process-level benchmark
|
+-- Startup
+-- Total runtime
+-- Memory
+-- Deployment size
Layer 2
Method-level benchmark
|
+-- CPU
+-- Allocations
+-- Throughput
This prevents startup and algorithm performance from being mixed together.
Control the Benchmark Environment
Run both versions under the same conditions.
Keep consistent:
For serious performance work, run the benchmark multiple times and document the environment.
Otherwise, the result may be impossible to reproduce.
Common Mistakes
Measuring Only One Execution
One process launch is not enough to establish a reliable performance difference.
Comparing Debug Builds
Always compare appropriate release builds.
Mixing Framework-Dependent and Self-Contained Builds
These deployment models have different characteristics.
Ignoring Cold Starts
For short-lived CLI tools, cold-start behavior can be the most important metric.
Measuring Only Total Runtime
Separate startup and application processing.
Assuming NativeAOT Is Always Faster
NativeAOT can improve startup while producing little or no improvement in steady-state processing.
Ignoring Compatibility
A library that depends on runtime code generation may require changes before it works correctly with NativeAOT.
Reporting Unsupported Precision
If two executions differ by a few milliseconds, do not turn that into a broad performance claim without repeated measurements.
Troubleshooting NativeAOT Build Problems
If the NativeAOT publish fails, first inspect the build output for compatibility diagnostics.
Common areas to investigate include:
Reflection
Dynamic code
Serialization
Assembly loading
Third-party dependencies
Source generators
Runtime type discovery
A useful troubleshooting approach is to isolate the problematic dependency.
For example:
Application
|
+-- Library A
+-- Library B
+-- Library C
Temporarily test whether the issue is associated with one library or one runtime feature.
Do not immediately rewrite the application.
First identify which part of the application is incompatible with the AOT compilation model.
When NativeAOT Is Worth Considering
NativeAOT deserves serious consideration when:
Startup time is important.
Applications run for short periods.
Deployment as a native executable is valuable.
Runtime installation should be minimized.
CLI tools are launched frequently.
Container startup matters.
The application's dependencies support AOT effectively.
It may be less compelling when:
The application runs continuously.
Startup represents an insignificant portion of total runtime.
The application depends heavily on dynamic runtime behavior.
The workload is dominated by external I/O.
AOT compatibility requires substantial architectural changes.
The decision should come from measurements rather than the technology label.
A Practical Benchmark Report
A useful report should contain more than a table of execution times.
Record:
Application version
.NET SDK version
OS
CPU
Memory
Runtime identifier
Publish configuration
Input dataset
Number of iterations
Cold/warm methodology
JIT configuration
NativeAOT configuration
Then report:
| Metric | JIT-Based .NET | NativeAOT | Difference |
|---|
| Cold startup | Measure | Measure | Calculate |
| Warm startup | Measure | Measure | Calculate |
| Total runtime | Measure | Measure | Calculate |
| Processing time | Measure | Measure | Calculate |
| Peak memory | Measure | Measure | Calculate |
| Executable size | Measure | Measure | Calculate |
| Publish size | Measure | Measure | Calculate |
This format makes the benchmark useful for an engineering decision.
Frequently Asked Questions
Is NativeAOT the same as ReadyToRun?
No. They are different compilation and deployment approaches. ReadyToRun can reduce some JIT work while retaining the .NET runtime model. NativeAOT produces a native executable using ahead-of-time compilation.
Does NativeAOT always improve startup time?
It can provide significant startup benefits for appropriate applications, but the actual improvement depends on the application, operating system, dependencies, and deployment configuration. Measure it.
Does NativeAOT always reduce memory usage?
No. Memory behavior depends on the application and its dependencies. Measure working set and peak memory rather than assuming a result.
Is NativeAOT useful for ASP.NET Core?
It can be useful for certain server workloads, particularly where startup and deployment characteristics matter, but the value proposition is different from a short-lived CLI tool.
Should I use BenchmarkDotNet for CLI startup?
Use process-level measurements for actual CLI startup and lifecycle behavior. BenchmarkDotNet is more appropriate for controlled method-level performance experiments.
Does NativeAOT eliminate the .NET runtime?
The deployment model produces a native executable rather than requiring the traditional JIT-based runtime execution model. However, the application still uses the relevant .NET runtime libraries and native runtime components incorporated into the application.
Conclusion
NativeAOT can be a strong option for .NET CLI applications, but its value should be demonstrated with measurements rather than assumed from the fact that the application is compiled ahead of time.
For short-lived command-line tools, startup time can represent a significant part of total execution time, making NativeAOT particularly interesting. For long-running workloads, steady-state processing performance may matter much more than startup.
A reliable comparison should therefore measure cold and warm startup, total execution time, processing time, memory usage, CPU consumption, and deployment size using the same workload and environment. Separating process-level startup measurements from method-level performance benchmarks also prevents misleading conclusions.
The best outcome of a NativeAOT benchmark is not simply proving that one deployment model is faster. It is identifying which part of the application's lifecycle benefits, by how much, and whether that improvement justifies the compatibility and build-time trade-offs of NativeAOT.