Arquivos PDB para aplicativo de produção e o sinalizador “Optimize code”

Question

Quando devo incluir arquivos PDB para uma versão de produção?Devo usar o Optimize code flag e como isso afetaria as informações que recebo de uma exceção?

Se houver um benefício perceptível no desempenho, eu gostaria de usar as otimizações, mas, caso contrário, prefiro ter informações de depuração precisas.O que normalmente é feito para um aplicativo de produção?

Answer 1

Quando você quiser ver nomes de arquivos de origem e números de linha em seus stacktraces, gere PDBs usando a opção pdb-only.A otimização é separada da geração de PDB, ou seja,você pode otimizar e gerar PDBs sem afetar o desempenho.

De a referência da linguagem C#

Se você usar /debug:full, esteja ciente de que há algum impacto na velocidade e no tamanho do código otimizado JIT e um pequeno impacto na qualidade do código com /debug:full.Recomendamos /debug:pdbonly ou nenhum PDB para gerar código de lançamento.

Answer 2

Para responder à sua primeira pergunta, você só precisa incluir PDBs para uma versão de produção se precisar de números de linha para seus relatórios de exceção.

Para responder à sua segunda pergunta, usar o sinalizador "Otimizar" com PDBs significa que qualquer stack "collapse" será refletido no rastreamento de pilha.Não tenho certeza se o número de linha real relatado pode estar errado - isso precisa de mais investigação.

Para responder à sua terceira pergunta, você pode ter o melhor dos dois mundos com um truque bastante interessante.As principais diferenças entre a compilação de depuração padrão e a compilação de versão padrão são que, ao fazer uma compilação de versão padrão, a otimização é ativada e os símbolos de depuração não são emitidos.Então, em quatro etapas:

1. Altere sua configuração de lançamento para emitir símbolos de depuração.Isso praticamente não afeta o desempenho do seu aplicativo e é muito útil se (quando?) você precisar depurar uma versão de lançamento do seu aplicativo.

2. Compile usando sua nova configuração de versão, ou seja, com símbolos de depuração e com otimização.Observe que 99% da otimização do código é feita pelo compilador JIT, não pelo compilador da linguagem.

3. Crie um arquivo de texto na pasta do seu aplicativo chamado xxxx.exe.ini (ou dll ou qualquer outro), onde xxxx é o nome do seu executável.Este arquivo de texto deve inicialmente se parecer com:

   [.NET Framework Debugging Control]
   GenerateTrackingInfo=0
   AllowOptimize=1
   

4. Com essas configurações, seu aplicativo funciona a toda velocidade.Quando você quiser depurar seu aplicativo ativando o rastreamento de depuração e possivelmente desativando a otimização de código (CIL), basta usar as seguintes configurações:

   [.NET Framework Debugging Control]
   GenerateTrackingInfo=1
   AllowOptimize=0 
   

EDITAR De acordo com o comentário de cateye, isso também pode funcionar em um ambiente hospedado como ASP.NET.

Answer 3

Não há necessidade de incluí-los em sua distribuição, mas você definitivamente deveria construí-los e mantê-los.Caso contrário, a depuração de um despejo de memória é praticamente impossível.

Eu também ativaria as otimizações.Embora torne a depuração mais difícil, os ganhos de desempenho geralmente não são triviais, dependendo da natureza do aplicativo.Vemos facilmente um desempenho superior a 10x em compilações de lançamento versus depuração para alguns algoritmos.