NativeAOT in .NET: Harder, Better, Faster, Stronger

Over the past few months, I’ve been diving (sinking?) deep into the world of .NET performance optimizations as part of trying to write better cloud services with less hassle. “Switch to Go! Or Rust!” - I hear you.
But now hear me out:
In this post, I’ll share my personal experiences and practical tips on using NativeAOT to achieve rapid startup times and a smaller memory footprint in .NET applications—without any hype, just what worked for me, and all without having to leave the comforting embrace of Satya Nadella (CEO, Microsoft).

What I Learned About NativeAOT

At its core, NativeAOT takes your managed code and compiles it ahead-of-time (AOT) into native machine code. This approach means that, unlike the usual Just-In-Time (JIT) compilation, your code is already optimized for the target platform when it starts up. Here’s what that translated to in my experiments:

  • Instant Startup: By eliminating the need for JIT, my applications were ready to go almost immediately—something especially noticeable during development and in serverless deployments.
  • Lean Memory Usage: Since only the code I actually needed was compiled into the binary, the overall memory footprint was significantly lower. This was a nice bonus when working with resource-constrained dev environments
    (My trusted Raspberry Pi).

The Technical Bits (Without the Jargon Overload)

1. Bye JIT Delays

I used to wait a few extra moments for the JIT compiler to kick in every time I started my application. With NativeAOT, those delays just disappeared. The result? A much snappier response time, which made a big difference in my local development cycles. That said, it’s worth noting that JIT can sometimes achieve better peak performance by dynamically optimizing hot paths at runtime, so NativeAOT trades runtime flexibility for faster startup.

However, where this shines practically is in scenarios where startup time is more critical than peak performance-
Such as in game servers we want to scale up and down quickly based on demand.

2. Smart Code Trimming

One of the more neat aspects of NativeAOT is how it prunes away unused code:

  • Trimming in Action: The compilation process analyzes your code and trims out what isn’t necessary. In my tests, this not only reduced the size of the executable but also helped in cutting down the memory usage.
  • Lean, Mean Binaries: The final binaries felt much more streamlined, which is a relief when every megabyte counts. Keep in mind, though, that self-contained NativeAOT binaries can still be larger than framework-dependent deployments because they include necessary runtime components.

3. Self-Contained Deployment

For me, one of the biggest advantages was that NativeAOT packages everything needed into a single binary (I know, Docker this, Docker that, but bear with me):

  • No Hidden Dependencies: There’s no need to worry about installing the right version of .NET on every machine where the app runs.

  • Simplified Distribution: This self-containment is particularly handy for deployment scenarios where managing dependencies can become a headache.

    Remember when games used to distribute their dedicated server executable for players to host themselves?
    Pepperidge Farm remembers.

A Practical Guide to Integrating NativeAOT

I found that getting started with NativeAOT was surprisingly straightforward. Here’s how I set it up in one of my .NET projects:

  1. Update the Project File:

    I added a few properties in my project file to enable AOT compilation:

    <PropertyGroup>
  <!-- Enable AOT compilation -->
  <PublishAot>true</PublishAot>
  <!-- Optionally, trim the output for a smaller binary -->
  <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

    Note: <PublishTrimmed> is optional but recommended for reducing binary size.

  2. Publish the Application:

    Using a simple publish command, I generated a native binary for my target platform. NativeAOT requires platform-specific compilation, so make sure to specify the correct runtime identifier (RID):

    dotnet publish -r win-x64 -c Release

    For cross-platform builds, you’ll need separate publish commands for each target (e.g., linux-x64, osx-arm64).

This process produced a native executable that performed exceptionally well in my tests. It was a simple yet effective way to see tangible improvements without a complete overhaul of my workflow (and I still haven’t learned Rust.. Joke’s on me).

Real-World Performance

In my experiments with console apps and microservices, I observed some very encouraging numbers:

  • Startup Time: My NativeAOT-compiled apps started almost instantly—sometimes in less than 10 milliseconds for a basic TCP server. This was a stark contrast to the slight lag I experienced with JIT-compiled versions.
  • Memory Footprint: By stripping away unnecessary code and avoiding the JIT overhead, I consistently saw a reduction in memory usage, which was especially beneficial for my little Raspberry Pi, and also for my wallet in the long run.

Practical Considerations

While I’ve had a positive experience with NativeAOT, there are a few things to keep in mind:

  • Reflection and Dynamic Code: If your project relies heavily on reflection or dynamic code generation, you might need to provide additional configuration (e.g., rd.xml files or [DynamicDependency] attributes) to prevent important code from being trimmed away.
  • Platform Compatibility: Make sure your target platforms and dependencies fully support NativeAOT. I encountered a few hiccups early on, but most issues were resolved by consulting the latest .NET NativeAOT documentation. Note that support for macOS ARM64 and some Linux distributions is still evolving.
  • Debugging: Debugging native binaries can be quite a bit more challenging compared to JIT-compiled apps because of the reduced runtime info. I found there are tools like WinDbg (Windows) or lldb (Linux/macOS) that can help, but be prepared for a slightly different debugging experience.. Or just publish JIT until you’re ready to ship a release.

Wrapping Up

Honestly, is this all that interesting?
Maybe not.
But when it comes to deploying on scale, especially as a solo developer or in a small team, shaving off a few milliseconds here and there can make a big difference cost-wise. Does this somehow make C# and .NET more appealing for high performance cloud-native development compared to Go, Rust or other modern languages? No, and if I rage-baited you into reading this far, I apologize.