Introdução

Quando penso em binários nativos com .NET, muitos devs imaginam imediatamente executáveis compactos, ultra-rápidos no startup, prontos para serverless. A realidade é mais nuançada. Native AOT (Ahead-Of-Time compilation) é poderoso — mas nem sempre é a resposta. Você pode compilar C# para nativo, sim. Mas qual é o preço real? Como funciona internamente? E em quais cenários faz realmente sentido investir tempo de compilação, limitações de reflection e binários maiores?

Eu criei este artigo porque vi muitos devs tentando usar Native AOT sem medir o trade-off completo. Neste guia, vou percorrer a stack de compilação desde o código C# processado pelo Roslyn até o código nativo emitido pelo ILC e mostrar quais restrições precisam entrar na decisão. A Parte 2 desta série complementa os conceitos com medições reproduzíveis de build, tamanho, startup, throughput e memória.

Pré-requisitos

  • Conhecimento de C# e .NET: experiência com .NET 8+ e familiaridade com conceitos como assemblies, IL (Intermediate Language) e garbage collection.
  • .NET SDK 9.0+: o artigo foca em .NET 9 e .NET 10 (LTS).
  • Noções de compilação: entender diferenças entre JIT (Just-In-Time) e compilação antecipada é útil, mas vou explicar os conceitos conforme necessário.
  • Familiaridade com performance: interpretação de métricas básicas de startup, memory footprint e throughput.

O que é Native AOT

Native AOT significa compilar seu código C# em binário nativo antes de executar, não durante a execução. Contraste com o modelo tradicional:

JIT (Just-In-Time):

  1. Você escreve C#, compila para IL (Intermediate Language)
  2. No startup do app, o JIT toma a IL
  3. JIT transforma IL em machine code dinamicamente conforme o código roda
  4. O .NET runtime (incluindo JIT, GC, todas as bibliotecas) rodam na memória

Native AOT:

  1. Você escreve C#, compila para IL
  2. Na máquina de build, o NativeAOT toolchain pega a IL, faz análise estática, remove código desnecessário (trimming)
  3. Transforma tudo em machine code nativo (x86-64, ARM, etc.) antes de você executar
  4. Resultado é um executável autocontido — sem JIT e sem exigir uma instalação prévia do .NET, mas com as partes necessárias do runtime

💡 Dica: Native AOT inclui uma versão reduzida das partes necessárias do CoreCLR e das bibliotecas, como GC e alocador. “Sem runtime instalado” é correto; “sem runtime” não é.

Variações de Compilação

Existe um espectro entre JIT puro e AOT puro:

  • JIT Padrão (Tier 0): Compila tudo no startup; depois otimiza com Tier 1 conforme uso
  • ReadyToRun (R2R): Compilação antecipada parcial; ainda precisa de runtime e JIT está disponível para código não pré-compilado
  • Native AOT Completo: Tudo pré-compilado; sem JIT (restrito por trimming e análise estática)

Native AOT é o mais agressivo em tradeoffs: ganhos extremos em startup, mas restrições rígidas em reflection.

Comparação visual entre JIT, R2R e Native AOT mostrando o quanto a compilação é antecipada e quando o runtime ainda é necessário

Stack de Compilação: Roslyn até Binário Nativo

Aqui está o coração técnico. Vou descrever exatamente o que acontece quando você roda dotnet publish -c Release --self-contained -r win-x64 /p:PublishAot=true.

1. Análise Estática com Roslyn

Roslyn é o compilador C# da Microsoft. Ele:

  • Lê .cs files
  • Monta uma árvore sintática (AST)
  • Resolve tipos, namespaces, símbolos
  • Gera IL (Intermediate Language) — um pseudocódigo agnóstico de plataforma

Para Native AOT, Roslyn não faz nada especial nesta etapa — a emissão de IL é idêntica. A “mágica” acontece depois.

2. IL (Intermediate Language)

IL é como “bytecode universal” do .NET. Um exemplo simples:

1

public int Add(int a, int b) => a + b;

Vira IL assim:

1
2
3
4
5
6

.method public int32 Add(int32 a, int32 b) cil managed {
  ldarg.0
  ldarg.1
  add
  ret
}

Isso é agnóstico de plataforma. Qualquer processador pode executar essas instruções (com uma VM ou compilador).

3. ILCompiler & Trimming (Análise de Reachability)

ILCompiler é o núcleo da magia Native AOT. Ele:

  1. Lê a IL gerada por Roslyn
  2. Analisa reachability: Começa do entry point (Main), segue cada chamada, cada campo acessado. “Se Main chamar Foo(), e Foo() chamar Bar(), então Bar() é alcançável.”
  3. Remove código desnecessário — tree-shaking. Se MetodoX nunca é chamado, é deletado do executável final.
  4. Detecta reflection problemática: Se você escreve Type.GetType("MinhaClasse"), o compilador não consegue saber estaticamente qual tipo você quer. Isso é um problema.
  5. Emite código nativo com o ILC usando o backend do RyuJIT

4. ILC e backend RyuJIT

O ILC conduz a compilação Native AOT e usa o backend do RyuJIT para transformar IL em código nativo para x86-64, ARM64 e outras arquiteturas compatíveis. O crossgen2 pertence ao pipeline mais associado ao ReadyToRun e não é uma etapa do publish Native AOT descrito aqui.

Não é o JIT tradicional (que roda em tempo de execução). É um compilador offline, com mais tempo para otimização.

Output: .obj files (objetos nativos), depois linkados em executável final.

5. Linkedição & Executável Final

Os .obj files são linkados com:

  • Runtime libraries (.NET GC, allocators, etc.)
  • Stdlib linkada (Collections, I/O, etc.)
  • Seu código compilado

Resultado: app.exe no Windows ou um executável sem extensão no Linux. A publicação é autocontida: não exige uma instalação prévia do .NET, mas inclui as partes necessárias do runtime e pode depender de bibliotecas nativas do sistema operacional.

Fluxo Visual Completo

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

C# Code
  ↓
[Roslyn Compiler]
  ↓ (emite)
IL (Intermediate Language)
  ↓
[ILCompiler - Análise de Reachability & Trimming]
  ↓ (remove dead code)
Otimized IL
  ↓
[ILC / backend RyuJIT]
  ↓ (transforma em)
Native Code (.obj files)
  ↓
[Linker]
  ↓ (linkado com runtime)
Executável autocontido (app.exe / app)

📝 Exemplo: Um app “Hello World” simples em JIT ocupa ~100MB (runtime + libs). Em AOT, o executável sozinho é ~5MB.

Trimming e Análise Estática: O Grande Obstáculo

Trimming é onde Native AOT brilha — e onde quebra.

O Problema da Reflection

Reflection permite código descobrir tipos, campos, métodos em tempo de execução:

1
2
3
4

// Reflection clássica
Type tipo = Type.GetType("MyApp.MyClass");
MethodInfo method = tipo.GetMethod("MyMethod");
object result = method.Invoke(instance, params);

Por que isso quebra AOT? O compilador estático não consegue saber em tempo de build qual tipo você vai pedir em Type.GetType(). Então, por segurança:

  • Ou compila todos os tipos (aumenta o binário)
  • Ou falha em runtime (crash)

Solução: TrimmerRootAssembly e Atributos

A Microsoft oferece configuração MSBuild e atributos para informar ao trimmer quais membros precisam ser preservados:

1
2
3

<ItemGroup>
  <TrimmerRootAssembly Include="AssemblyComReflection" />
</ItemGroup>

1
2
3
4
5
6

static void ProcessType(
    [DynamicallyAccessedMembers(
        DynamicallyAccessedMemberTypes.PublicMethods)] Type tipo)
{
    // Os métodos públicos de "tipo" serão preservados.
}

Esses mecanismos não tornam qualquer código automaticamente compatível com AOT. Eles explicitam partes do grafo que a análise estática não conseguiria inferir e ainda exigem testes do artefato publicado.

Análise Conservative vs Aggressive

  • Conservative: Trimmer presume que qualquer Type.GetType() pode ser usado; mantém tudo (maior binário, mas seguro)
  • Aggressive: Trimmer remove tudo que não é provado alcançável (menor binário, mas pode quebrar em runtime)

Artigos sobre Native AOT sempre recomendam “teste bastante” — e com razão.

Trade-offs de Performance

Native AOT não é uma bala de prata. Aqui estão os reais tradeoffs:

1. Startup: vantagem frequente do Native AOT

Native AOT remove a compilação JIT durante a execução e frequentemente reduz o tempo até a primeira resposta. No laboratório da Parte 2, a mediana foi 63,794 ms para Native AOT e 587,644 ms para JIT framework-dependent em 30 processos. Esses valores descrevem um workload, hardware e ambiente específicos; em serverless gerenciado, o cold start também inclui decisões do provedor, sandbox, rede e configuração.

⚠️ Atenção: AOT coloca todo o tempo de compilação na máquina de build, não no cliente. Se você demora 15 minutos compilando sua app em AOT, bem… existem tradeoffs.

2. Memória e tamanho de distribuição

Uma publicação JIT framework-dependent pode ter poucos arquivos porque pressupõe um runtime compatível instalado fora do artefato. JIT self-contained, ReadyToRun self-contained e Native AOT incluem o runtime necessário, portanto a comparação precisa usar unidades equivalentes. No laboratório da Parte 2, Native AOT ocupou 28,3 MB descompactados e 41 MB de working set máximo mediano; JIT FDD ocupou 165,7 KB de artefato, sem contar o runtime instalado, e 103 MB de working set máximo mediano.

Esses números não estabelecem uma proporção universal. Dependências, genéricos, recursos, símbolos, código preservado para reflection e páginas efetivamente tocadas alteram tanto o tamanho quanto a memória residente.

3. Throughput e Otimização

AspectoJITAOT
TieringSim (Tier 0 → 1 otimização)Não (fixo)
ProfilingJit ajusta conforme usoEstático (sem profiling)
HotpathMelhora com tempoFixo (sem warm-up)

O JIT tem vantagem de adaptação em processos longos porque tiered compilation e dynamic PGO podem observar tipos e caminhos quentes e recompilar métodos. Isso não garante vitória: Native AOT pode empatar ou superar o JIT em workloads específicos e estáveis. Throughput, latência de cauda, CPU e memória precisam ser medidos na aplicação real.

Resumo: Quando Usar?

  • Primeira resposta e processos efêmeros: compare Native AOT e ReadyToRun, medindo também publish, distribuição e compatibilidade.
  • Throughput e latência aquecidos: compare JIT com tiering/dynamic PGO e Native AOT sob a mesma carga.
  • Densidade e operação: inclua RSS/working set, runtime compartilhado, observabilidade, plugins e frequência de atualização.

Exemplo Prático: CLI Tool em Native AOT

Vou mostrar um exemplo real: um String Analyzer CLI que conta frequência de caracteres em arquivos.

A razão de escolher CLI: reflection mínima, I/O puro, ideal para AOT.

Estrutura do Projeto

1
2
3
4
5
6
7

BlogSamples/
├── NativeAot/
│   ├── CliExample/
│   │   ├── StringAnalyzer.Console.csproj
│   │   ├── Program.cs
│   │   ├── AnalyzerService.cs
│   │   ├── README.md

Arquivo .csproj com AOT Enabled

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <PublishAot>true</PublishAot>
    <TrimMode>link</TrimMode>
    <RuntimeIdentifiers>win-x64;linux-x64;osx-arm64</RuntimeIdentifiers>
    <SelfContained>true</SelfContained>
  </PropertyGroup>
</Project>

Destaques:

  • PublishAot=true ativa o compilador Native AOT
  • TrimMode=link ativa trimming agressivo
  • RuntimeIdentifiers lista plataformas alvo
  • O projeto não adiciona dependências externas

Código Exemplo: Program.cs

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

string[] commandArguments = Environment.GetCommandLineArgs();
if (commandArguments.Length < 2)
{
  Console.Error.WriteLine("Uso: StringAnalyzer.Console <arquivo>");
  return 1;
}

string filePath = commandArguments[1];
if (!File.Exists(filePath))
{
  Console.Error.WriteLine($"Arquivo '{filePath}' não encontrado.");
  return 1;
}

var analyzer = new AnalyzerService();
AnalysisResult result = analyzer.Analyze(filePath);
Console.WriteLine($"Total de caracteres: {result.TotalChars:N0}");
return 0;

Por que isso é AOT-friendly:

  • Parsing explícito com APIs da biblioteca padrão
  • Nenhum carregamento dinâmico de assemblies ou emissão de código
  • I/O simples, sem patterns avançados

Compilar e Executar

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Restore
dotnet restore

# Publish para AOT (windows x64)
dotnet publish -c Release -r win-x64 /p:PublishAot=true

# Executável sai em: bin/Release/net10.0/win-x64/publish/StringAnalyzer.Console.exe
# Tamanho típico: 8–12 MB

# Teste
./StringAnalyzer.Console.exe myfile.txt

📂 Código Fonte: O exemplo completo está disponível no repositório de exemplos do blog: BlogSamples/NativeAot/CliExample/

Dicas e Boas Práticas

  1. Prefira parsing explícito ou uma biblioteca validada para AOT O exemplo usa apenas APIs da biblioteca padrão. Ao adotar uma biblioteca de CLI, publique e teste o artefato Native AOT para detectar reflection dinâmica ou avisos de trimming.

  2. Minimize reflection; use source generators quando possível Se você precisa de serialização, use System.Text.Json com source generators (JsonSourceGenerationContext). Evite Newtonsoft.Json ou reflection pura em AOT.

  3. Teste AOT warnings durante desenvolvimento Compile com dotnet build e cheque warnings. Não deixe para descobrir problemas em produção. Use -Werror para converter warnings em erros durante CI.

  4. Meça o tamanho da distribuição Compare o diretório publicado e o artefato compactado, declarando se o runtime está incluído. Às vezes, remover uma dependência economiza mais do que alterar o modo de compilação.

  5. Considere ReadyToRun como alternativa Se você quer startup rápido mas não pode abrir mão de reflection, ReadyToRun é um meio-termo. Compile com PublishReadyToRun=true em vez de PublishAot=true.

  6. Teste em ambientes similares à produção AOT binário compilado em Windows pode não rodar em Linux (arquivos Object linkam diferente). Sempre compile/teste para o target runtime específico.

  7. Compare unidades equivalentes Um assembly IL framework-dependent exclui o runtime instalado, enquanto Native AOT é autocontido. Para edge, IoT ou atualizações frequentes, compare bytes efetivamente transferidos e armazenamento total.

  8. Documente dependências AOT-compatibility Se você usa bibliotecas de terceiros, confirme explicitamente que são AOT-compatible. Mantenha isso em seu README de deployment.

Resumo Objetivo

  • Native AOT — compilação antecipada de C# em código nativo para um RID específico, eliminando o JIT em execução e incluindo as partes necessárias do runtime sem exigir instalação prévia do .NET.

  • Stack de compilação — Roslyn gera IL; o ILC analisa alcance e compatibilidade, usa o backend RyuJIT para emitir código nativo e entrega objetos ao linker da plataforma.

  • Trimming — remoção automática de código não alcançável (tree-shaking); quebra com reflection dinâmica (Type.GetType()), requer TrimmerRootAssembly e DynamicallyAccessedMembers para avisar o compilador.

  • Startup time — Native AOT remove o trabalho de JIT em execução, mas o ganho deve ser medido no hardware e no ambiente de hospedagem reais.

  • Throughput — JIT com tiering e dynamic PGO adapta código quente em execução; Native AOT pode empatar ou vencer em cargas específicas, portanto não há resultado universal.

  • Decisão orientada a métricas — primeira resposta, p95/p99, throughput, CPU, memória residente, tamanho de distribuição, compatibilidade e tempo de build devem preceder rótulos como CLI ou servidor.

  • Trade-offs — startup, memória, tamanho, throughput, compatibilidade e tempo de build variam conforme o workload; a decisão exige medir distribuições equivalentes.

Leia Também

Referências