diferença de desempenho entre um assembly .NET construído em modo de depuração e liberação?

votos
14

Alguns desenvolvedores anteriores colocar algumas montagens que foram construídas no modo de depuração em produção. Vale a pena recompilar-los no modo de versão e reimplantar-los? Se há apenas um aumento de desempenho de 1-2%, eu provavelmente deixá-los lá. Por outro lado, um aumento de 10-20% pode mudar minha mente.

Publicado 19/05/2009 em 18:12
fonte usuário
Em outras línguas...                            


7 respostas

votos
17

Eu tinha essa mesma pergunta cerca de um ano atrás, porque estávamos tendo grandes problemas de desempenho na produção. Como foi explicado para mim de MS Premier apoiar as versões de depuração de compilação incluem ganchos para depuração que pode resultar em cerca de 1 - 10% de aumento no consumo de memória, dependendo do que o aplicativo faz.

Se você não está tendo problemas, em seguida, deixá-los sozinhos, mas se você está tendo problemas com o consumo de memória, em seguida, vá em frente e recompilar / implantar.

Respondeu 19/05/2009 em 18:24
fonte usuário

votos
6

Na minha experiência, eu vi uma diferença de 30-40%. Este foi com DotNetZip , uma biblioteca que faz a criptografia, compressão e um pequeno arquivo i / o. Mais de 85% do tempo foi gasto em criptografia e compressão, apenas movendo bytes ao redor.

Respondeu 19/05/2009 em 18:14
fonte usuário

votos
4

Se você olhar o código IL gerado para Debug e Release cria as diferenças são geralmente muito pequena. A maioria das diferenças residem em comandos nop adicionais em pontos importantes fontes para apoiar Editar e continuar e linha de fonte de depuração. No entanto, quando o tempo de execução .NET realmente EIC o MSIL o conjunto de tempo de execução é quase idêntica. A maior diferença vem quando um depurador é anexado. Isso vai evitar que o JIT de otimizar o código de funcionamento real.

versões de lançamento são muitas vezes muito menor, mas também porque eles simplesmente não incluir o máximo de código. Há pode ser manchas de código cercado com #if instruções de depuração, bem como atributos condicionais que instruem o compilador para omitir chamadas para métodos no modo de versão (como Debug.WriteLine).

Descobri que os métodos Debug.WriteLine e Trace.WriteLine, quando deixadas no código de produção e ter uma significativa implicações de desempenho, mesmo se um depurador não está anexado.

Respondeu 19/05/2009 em 20:09
fonte usuário

votos
2

Vale a pena notar que o código de lançamento também remove algumas coisas pré-processador como:

#if DEBUG
...
#endif

Ele também remove Debug.WriteLine, Debug.Assert, e algumas outras coisas no namespace System.Diagnostics, que pode ser útil em testes, mas são inúteis no código bem projetado para a compilação de lançamento.

Respondeu 19/05/2009 em 18:34
fonte usuário

votos
1

Descobri que a diferença de desempenho aumenta exponencialmente com a complexidade do código - uma aplicação simples só pode ver uma diferença de 5%, mas já vi tanto quanto uma desaceleração de 50% em aplicações complexas, especialmente as que envolvem dados maior estruturas como matrizes ou mapas.

Há, naturalmente, a possibilidade de que o código de depuração Poderia ser um pouco diferente também, dependendo de como você está set-up - olhar para afirmações, por exemplo.

Respondeu 19/05/2009 em 18:27
fonte usuário

votos
1

Geralmente você vai ver um benefício porque a versão de lançamento é normalmente compilado com otimizações usando a /optimizeopção do compilador. No entanto, quão grande é a diferença será vai depender do seu conjunto específico - você vai precisar para o perfil.

Respondeu 19/05/2009 em 18:19
fonte usuário

votos
0

Outro argumento contra o uso de compilações de depuração na produção é porque eles consomem muito mais memória desde símbolos de depuração são obrigados a ser carregado.

Respondeu 19/05/2009 em 18:18
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more