Creating a large JSON with Utf8JsonWriter is very slow in a native AOT library

Question

Creating a large JSON with Utf8JsonWriter is very slow in a native AOT library

Don Z 60

Hello,

In a personal project I'm creating a fairly large JSON document, 150MB, using Utf8JsonWriter in C#. It is reasonably fast when compiled to managed, NET 10, code - it finishes in 6 seconds. However, when published to native AOT, the same process takes 21 seconds, so ~3.5 times slower. I would have expected it to be the other way around, and the native version to be significantly faster.

Is there a reason why Utf8JsonWriter is performing worse in native AOT build, as compared to managed NET10? Thank you.

Viorel 127K Reputation points

2026-06-20T12:23:26.97+00:00

Maybe this file format is not suitable in this case.

Answer accepted by question author

Tom Tran (WICLOUD CORPORATION) 5,295 Microsoft External Staff Moderator

Hi @Don Z ,

From what I found, I couldn’t find a confirmed Utf8JsonWriter-specific issue in Native AOT.

Native AOT can improve startup time, app size, and memory usage, but it does not always make long-running code faster. For this kind of workload, the managed JIT may still perform better because it can optimize hot code while the application is running. Native AOT code is fixed at publish time. Microsoft documents the AOT speed/size trade-off here: Optimize AOT deployments.

I also found this article showing similar benchmark behavior: Native AOT can win when startup matters, but managed code can match or beat it after startup.

Disclaimer: This is a non-Microsoft article. I found it useful for comparison, but please review any ads or downloads on the site carefully before installing anything.

For your case, I would first try publishing the AOT version with speed optimization and compare again:

<PropertyGroup>
  <PublishAot>true</PublishAot>
  <OptimizationPreference>Speed</OptimizationPreference>
</PropertyGroup>

If the gap is still large, I would compare the GC settings next. Writing a large JSON document can create a lot of allocation and buffer pressure, so it is worth checking whether both builds are using comparable GC behavior. For example, you can test with Server GC enabled:

<PropertyGroup>
  <ServerGarbageCollection>true</ServerGarbageCollection>
</PropertyGroup>

If the AOT build is still around 3.5x slower after those checks, a small reproducible benchmark would be the best next step to narrow this down.

Hope this helps. If the information I provided was helpful to you, I would greatly appreciate it if you could follow the instructions here.

Don Z 60

Thank you Tom. We've investigated further, and determined that the slowdown is not due to Utf8JsonWriter. The writer actually works very well in native AOT build.

It is something else that is causing the AOT build to run 3.5x slower than the managed version, but we haven't narrowed it down to anything particular yet.

We've done the following optimizations on project level, which shredded a second (from 21 to 20 seconds):


<PropertyGroup>
	<PublishAot>true</PublishAot>
	<StripSymbols>true</StripSymbols>
	<PublishTrimmed>true</PublishTrimmed>
	<TrimMode>full</TrimMode>
	<AllowUnsafeBlocks>True</AllowUnsafeBlocks>
	<!-- C# → IL optimisation (Roslyn) -->
	<OptimizationPreference>Speed</OptimizationPreference>
	<!-- IL → native optimisation (ILC) — was missing; this is the dominant one for AOT -->
	<IlcOptimizationPreference>Speed</IlcOptimizationPreference>
	<!-- No dynamic reflection used; allows ILC to eliminate whole subsystems -->
	<IlcDisableReflection>true</IlcDisableReflection>
	<!-- Target the CPU the binary is compiled on for full AVX2/BMI2 vectorisation.
	     Change to avx2,bmi2 for a redistributable targeting modern-but-generic x64. -->
	<IlcInstructionSet>native</IlcInstructionSet>
	<ServerGarbageCollection>true</ServerGarbageCollection>
	<PlatformTarget>AnyCPU</PlatformTarget>
</PropertyGroup>

Tom Tran (WICLOUD CORPORATION) 5,295 Reputation points Microsoft External Staff Moderator

2026-06-24T10:20:30.52+00:00

Hi @Don Z ,

Thanks for the follow-up. I think your latest conclusion makes a lot of sense.

At this point, this does not look like a Utf8JsonWriter problem anymore. It looks more like the writer was where the slowdown became visible.

The Dynamic PGO explanation fits well. In the managed build, the JIT can watch the hot path and then improve it after warmup with better inlining and devirtualization. Native AOT does not get that runtime feedback loop, so it has to rely on the code produced at publish time. Native AOT is mainly useful for startup time, app size, and memory footprint, not guaranteed faster steady-state throughput: Native AOT deployment overview.

Your AOT settings look like the right knobs to try. Since they only reduced the time slightly, I would not expect another project-level setting to close the full gap.

I would look next at the hot path that feeds the writer: dictionary lookups, interface calls, comparer calls, and struct copies. Those are exactly the kinds of patterns the JIT can improve after warmup, while AOT cannot use runtime profile data. If possible, try reducing interface or virtual calls inside that loop, use concrete or sealed types where it makes sense, and check whether CA1859 reports anything useful: CA1859: Use concrete types when possible.

So I think your direction is right: this looks like an AOT-vs-JIT hot-path optimization gap, not a JSON writer issue. Profiling the AOT build around that loop should be the most useful next step.

4 additional answers

Your answer

Viorel 127K Reputation points

2026-06-20T12:23:26.97+00:00

Maybe this file format is not suitable in this case.
Don Z 60 Reputation points

2026-06-23T15:31:28.98+00:00

Thank you Tom. We've investigated further, and determined that the slowdown is not due to Utf8JsonWriter. The writer actually works very well in native AOT build.

It is something else that is causing the AOT build to run 3.5x slower than the managed version, but we haven't narrowed it down to anything particular yet.

We've done the following optimizations on project level, which shredded a second (from 21 to 20 seconds):

<PropertyGroup> <PublishAot>true</PublishAot> <StripSymbols>true</StripSymbols> <PublishTrimmed>true</PublishTrimmed> <TrimMode>full</TrimMode> <AllowUnsafeBlocks>True</AllowUnsafeBlocks>  <OptimizationPreference>Speed</OptimizationPreference>  <IlcOptimizationPreference>Speed</IlcOptimizationPreference>  <IlcDisableReflection>true</IlcDisableReflection>  <IlcInstructionSet>native</IlcInstructionSet> <ServerGarbageCollection>true</ServerGarbageCollection> <PlatformTarget>AnyCPU</PlatformTarget> </PropertyGroup>
Tom Tran (WICLOUD CORPORATION) 5,295 Reputation points Microsoft External Staff Moderator

2026-06-24T10:20:30.52+00:00

Hi @Don Z ,

Thanks for the follow-up. I think your latest conclusion makes a lot of sense.

At this point, this does not look like a Utf8JsonWriter problem anymore. It looks more like the writer was where the slowdown became visible.

The Dynamic PGO explanation fits well. In the managed build, the JIT can watch the hot path and then improve it after warmup with better inlining and devirtualization. Native AOT does not get that runtime feedback loop, so it has to rely on the code produced at publish time. Native AOT is mainly useful for startup time, app size, and memory footprint, not guaranteed faster steady-state throughput: Native AOT deployment overview.

Your AOT settings look like the right knobs to try. Since they only reduced the time slightly, I would not expect another project-level setting to close the full gap.

I would look next at the hot path that feeds the writer: dictionary lookups, interface calls, comparer calls, and struct copies. Those are exactly the kinds of patterns the JIT can improve after warmup, while AOT cannot use runtime profile data. If possible, try reducing interface or virtual calls inside that loop, use concrete or sealed types where it makes sense, and check whether CA1859 reports anything useful: CA1859: Use concrete types when possible.

So I think your direction is right: this looks like an AOT-vs-JIT hot-path optimization gap, not a JSON writer issue. Profiling the AOT build around that loop should be the most useful next step.

Answer 1

Bruce (SqlWork.com) 84,251

Be sure you are not using reflection to get the values to write. AOT does not support dynamic code, so if using reflection, you should use the precompiled options.

Don Z 60 Reputation points

2026-06-20T12:59:56.14+00:00

Thank you for your answer. I don't use reflection or anything dynamic. I don't even use the Json deserializer and manually generate the Json using Utf8JsonWriter to avoid the AOT native limitations.
Bruce (SqlWork.com) 84,251 Reputation points

2026-06-20T13:03:02.7666667+00:00

I still suspect the code that calls Utf8JsonWriter. The other common issue is the GC can be a lot slower with AOT.

Note: AOT code is not faster at runtime, it just has faster startup because a JIT is not performed. As it has runtime information, the JIT code may be more performant.

Answer 2

The investigation points to the following:

Loss of Dynamic PGO + tiered re-JIT (the core AOT-vs-JIT gap)

In .NET 8+, the managed JIT enables Dynamic PGO by default. It observes types at runtime, then devirtualizes/inlines hot virtual & interface calls and biases hot branches. Native AOT does a single static compile with no runtime profile — roughly tier-1 code quality but profile-blind.

This codebase is almost a worst case for that gap. The hot loop does:

Many generic dictionary lookups.

Interface dispatch.

Lots of struct copies, ReadOnlySpan<char> splits, and EqualityComparer<T> calls.

A JIT-with-PGO build devirtualizes and inlines much of this after warmup; AOT cannot. For dispatch/lookup-bound loops this alone is commonly ~1.3–2×.

Answer 3

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 4

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more