Perfis e Configurações de Build

Os perfis do Cargo controlam a otimização, informações de depuração, estratégia de pânico e otimização em tempo de linkagem. Ajustá-los é como você troca o tempo de compilação por velocidade de tempo de execução e tamanho do binário.

Receita

[profile.dev]
opt-level = 0
debug = true
 
[profile.release]
opt-level = 3
lto = "thin"
codegen-units = 1
strip = "symbols"

Quando usar isso: Para enviar binários de produção, builds de release em CI ou para encolher artefatos de deploy.

Exemplo de Trabalho

Perfil de release para um serviço de API Axum:

[profile.release]
opt-level = 3
lto = "thin"
codegen-units = 1
panic = "abort"
strip = "symbols"
 
[profile.release-fast]
inherits = "release"
lto = false
codegen-units = 16

cargo build --release
cargo build --profile release-fast

O que isso demonstra:

opt-level = 3 maximiza o desempenho em tempo de execução
Thin LTO equilibra o tempo de linkagem e o inlining entre crates
codegen-units = 1 melhora a otimização ao custo do tempo de compilação
Perfis personalizados herdam de release ou dev

Mergulho Profundo

Chaves Comuns de Perfil

Chave	Típico em Dev	Típico em Release
`opt-level`	`0`	`3` ou `s` para tamanho
`debug`	`true`	`false` ou limitado
`lto`	`false`	`thin` ou `fat`
`codegen-units`	`256`	`1` para performance máxima
`panic`	`unwind`	`abort` para binários menores
`strip`	nenhum	`symbols` ou `debuginfo`

Release Orientado a Tamanho

[profile.release-size]
inherits = "release"
opt-level = "z"
lto = true
panic = "abort"
strip = "symbols"

opt-level = "s" ou "z" favorece binários menores
Fat LTO pode encolher ainda mais, mas linka mais devagar
Combine com cargo bloat para encontrar símbolos grandes

`RUSTFLAGS` e CPU de Destino

RUSTFLAGS="-C target-cpu=native" cargo build --release

target-cpu=native usa recursos da CPU do host (não é portátil)
Defina em .cargo/config.toml para padrões para toda a equipe
Documente os requisitos de portabilidade ao usar ajuste nativo

Armadilhas

Profiling de builds de depuração - caminhos quentes não se parecem em nada com release. Correção: sempre faça benchmark com --release.
Fat LTO em CI - timeouts na etapa de linkagem. Correção: use thin em CI, fat apenas para artefatos de release finais.
panic = "abort" sem testar - suposições de limpeza Drop baseadas em unwinding quebram. Correção: verifique se FFI e guards de escopo ainda se comportam corretamente.
Erros de digitação em perfis herdados - inherits deve nomear um perfil existente. Correção: cargo build --profile foo localmente antes do CI.
Strip muito agressivo - você perde backtraces úteis em produção. Correção: mantenha os símbolos de depuração em um arquivo separado ou use apenas strip = "debuginfo".

Alternativas

Alternativa	Usar Quando	Não Usar Quando
`opt-level = 2`	Compilação mais rápida, performance próxima à de release	Ajuste de latência de última milha
`cargo bloat --release`	Encontrar regressões de tamanho	Provar melhorias algorítmicas
`sccache` / `mold`	Velocidade de compilação/linkagem em CI	Substituir escolhas de perfil corretas

FAQs

Qual é a diferença entre LTO thin e fat?

Thin LTO otimiza entre crates com links mais rápidos. Fat LTO é mais agressivo e lento, muitas vezes produzindo binários menores ou mais rápidos.

Devo definir codegen-units para 1?

Para binários de release finais onde o tempo de compilação é aceitável, sim. Para iteração de desenvolvimento, mantenha os padrões.

Como acelerar builds de desenvolvimento?

Use cargo check, divida crates do workspace, desative features padrão não utilizadas e considere opt-level = 1 em um perfil dev-fast personalizado.

O que strip = symbols faz?

Remove tabelas de símbolos do binário, reduzindo o tamanho. Mantenha informações de depuração separadas se precisar de relatórios de crash com símbolos.

As dependências podem ter perfis diferentes?

[profile.release.package.foo] substitui configurações por crate de dependência (por exemplo, otimizar sempre uma dependência de caminho quente).

Como panic = abort afeta Result?

Result ainda funciona; apenas panics abortam o processo em vez de fazer unwinding. catch_unwind não captura mais panics.

O que é compilação incremental?

Ativado em dev por padrão. Builds de release geralmente o desativam para uma saída otimizada determinística.

Como fazer benchmark de mudanças de perfil?

Use Criterion com as mesmas entradas entre os perfis; compare o tempo de relógio e o tamanho do binário com ls -la target/release/foo.

O LTO afeta recursos de tempo de compilação?

LTO pode fazer inlining entre limites de crates, expondo otimizações, mas também etapas de linkagem mais longas e maior uso de memória durante a build.

Onde defino rustflags para todo o workspace?

.cargo/config.toml sob [build] rustflags = [...] aplica-se a todos os membros do workspace, a menos que substituído.

Relacionados

Noções Básicas do Cargo - comandos de build
Reduzindo o Tamanho do Binário - táticas de tamanho
Ajuste de Release - foco em performance
Subcomandos Úteis do Cargo - cargo bloat

Versões da Pilha: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4 e Polars 0.46+.

Perfis e Configurações de Build

Receita

[profile.dev]
opt-level = 0
debug = true
 
[profile.release]
opt-level = 3
lto = "thin"
codegen-units = 1
strip = "symbols"

Quando usar isso: Para enviar binários de produção, builds de release em CI ou para encolher artefatos de deploy.

Exemplo de Trabalho

Perfil de release para um serviço de API Axum:

[profile.release]
opt-level = 3
lto = "thin"
codegen-units = 1
panic = "abort"
strip = "symbols"
 
[profile.release-fast]
inherits = "release"
lto = false
codegen-units = 16

cargo build --release
cargo build --profile release-fast

O que isso demonstra:

opt-level = 3 maximiza o desempenho em tempo de execução
Thin LTO equilibra o tempo de linkagem e o inlining entre crates
codegen-units = 1 melhora a otimização ao custo do tempo de compilação
Perfis personalizados herdam de release ou dev

Mergulho Profundo

Chaves Comuns de Perfil

Chave	Típico em Dev	Típico em Release
`opt-level`	`0`	`3` ou `s` para tamanho
`debug`	`true`	`false` ou limitado
`lto`	`false`	`thin` ou `fat`
`codegen-units`	`256`	`1` para performance máxima
`panic`	`unwind`	`abort` para binários menores
`strip`	nenhum	`symbols` ou `debuginfo`

Release Orientado a Tamanho

[profile.release-size]
inherits = "release"
opt-level = "z"
lto = true
panic = "abort"
strip = "symbols"

opt-level = "s" ou "z" favorece binários menores
Fat LTO pode encolher ainda mais, mas linka mais devagar
Combine com cargo bloat para encontrar símbolos grandes

`RUSTFLAGS` e CPU de Destino

RUSTFLAGS="-C target-cpu=native" cargo build --release

target-cpu=native usa recursos da CPU do host (não é portátil)
Defina em .cargo/config.toml para padrões para toda a equipe
Documente os requisitos de portabilidade ao usar ajuste nativo

Armadilhas

Profiling de builds de depuração - caminhos quentes não se parecem em nada com release. Correção: sempre faça benchmark com --release.
Fat LTO em CI - timeouts na etapa de linkagem. Correção: use thin em CI, fat apenas para artefatos de release finais.
panic = "abort" sem testar - suposições de limpeza Drop baseadas em unwinding quebram. Correção: verifique se FFI e guards de escopo ainda se comportam corretamente.
Erros de digitação em perfis herdados - inherits deve nomear um perfil existente. Correção: cargo build --profile foo localmente antes do CI.
Strip muito agressivo - você perde backtraces úteis em produção. Correção: mantenha os símbolos de depuração em um arquivo separado ou use apenas strip = "debuginfo".

Alternativas

Alternativa	Usar Quando	Não Usar Quando
`opt-level = 2`	Compilação mais rápida, performance próxima à de release	Ajuste de latência de última milha
`cargo bloat --release`	Encontrar regressões de tamanho	Provar melhorias algorítmicas
`sccache` / `mold`	Velocidade de compilação/linkagem em CI	Substituir escolhas de perfil corretas

FAQs

Qual é a diferença entre LTO thin e fat?

Thin LTO otimiza entre crates com links mais rápidos. Fat LTO é mais agressivo e lento, muitas vezes produzindo binários menores ou mais rápidos.

Devo definir codegen-units para 1?

Para binários de release finais onde o tempo de compilação é aceitável, sim. Para iteração de desenvolvimento, mantenha os padrões.

Como acelerar builds de desenvolvimento?

Use cargo check, divida crates do workspace, desative features padrão não utilizadas e considere opt-level = 1 em um perfil dev-fast personalizado.

O que strip = symbols faz?

Remove tabelas de símbolos do binário, reduzindo o tamanho. Mantenha informações de depuração separadas se precisar de relatórios de crash com símbolos.

As dependências podem ter perfis diferentes?

[profile.release.package.foo] substitui configurações por crate de dependência (por exemplo, otimizar sempre uma dependência de caminho quente).

Como panic = abort afeta Result?

Result ainda funciona; apenas panics abortam o processo em vez de fazer unwinding. catch_unwind não captura mais panics.

O que é compilação incremental?

Ativado em dev por padrão. Builds de release geralmente o desativam para uma saída otimizada determinística.

Como fazer benchmark de mudanças de perfil?

Use Criterion com as mesmas entradas entre os perfis; compare o tempo de relógio e o tamanho do binário com ls -la target/release/foo.

O LTO afeta recursos de tempo de compilação?

LTO pode fazer inlining entre limites de crates, expondo otimizações, mas também etapas de linkagem mais longas e maior uso de memória durante a build.

Onde defino rustflags para todo o workspace?

.cargo/config.toml sob [build] rustflags = [...] aplica-se a todos os membros do workspace, a menos que substituído.

Relacionados

Noções Básicas do Cargo - comandos de build
Reduzindo o Tamanho do Binário - táticas de tamanho
Ajuste de Release - foco em performance
Subcomandos Úteis do Cargo - cargo bloat

Versões da Pilha: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4 e Polars 0.46+.

Perfis e Configurações de Build

Buscar na documentação

Perfis e Configurações de Build