Por que é tão lento aspnet_compiler.exe (e ele pode ser feito mais rápido)?
-
08-07-2019 - |
Pergunta
Durante o nosso processo de construção corremos aspnet_compiler.exe
contra os nossos sites para se certificar de que todo o material de ligação tardia em ASP.NET/MVC realmente constrói (Não sei nada sobre ASP.NET, mas estou certo de que isto é necessário para evitar encontrar as falhas em tempo de execução).
Os nossos sites são bastante grandes em tamanho, com algumas centenas de páginas / views / controles / etc. mas o tempo parece excessivo na faixa de 10-15 minutos (para referência, este é mais do que leva toda a solução com cerca de 40 projetos para compilar, e nós estamos apenas pré-compilar dois projetos de website).
Eu duvido que o hardware é a questão como eu estou correndo no mais recente chip quad core Intel, com 4GB de RAM e disco rígido de um WD Velociraptor 10.000 rpm. E parte do que é estranho é que o EXE não parece estar usando muito CPU (1-5%) e não parecem estar fazendo uma enorme quantidade de I / O quer.
Então ... este é um problema conhecido? Por que é tão lento? E há alguma maneira de acelerá-lo?
Nota: Para esclarecer um par de coisas que as pessoas têm respondidas sobre, eu não estou falando sobre a compilação de código dentro do Visual Studio. Estamos usando projetos de aplicativos web já, e a velocidade de compilação dos que não é a questão. O problema é a pré-compilação do site após desses projetos já foram compilados ( ver esta página MSDN para obter mais detalhes ) como parte do script dev construção. Estamos realizando no local pré-compilação, não copiar os arquivos para um diretório de destino.
Solução
- Compiler deve gerar segunda code-behind arquivo para cada página .aspx, Verifique
- Durante a compilação, aspnet_compiler.exe irá copiar todos os arquivos do site web para o diretório de saída, incluindo CSS, JS e imagens.
Você obterá melhores tempos de compilação usando aplicação em vez de modelo web site.
Outras dicas
Mudar para compilador Roslyn provavelmente irá melhorar significativamente o tempo de pré-compilação. Aqui está um bom artigo sobre ele: http://blogs.msdn.com/b/webdev/archive/2014/05/12/enabling-the-net-compiler-platform-roslyn-in-asp -net-applications.aspx .
Além disso, certifique-se que a compilação lote é ativado definindo atributo lote para true no elemento compilação.
Simplesmente, os usos aspnet_compiler
que é efetivamente um "bloqueio compilador global" sempre que começa pré-compilação de qualquer página aspx individual; é basicamente só é permitido para compilar cada página sequencialmente.
Há razões para isso (embora eu, pessoalmente, discordar deles) - principalmente, a fim de detectar e evitar referências circulares causando um loop infinito de tipos, bem como assegurar que todas as dependências estão devidamente construída antes da página que requer é compilado , eles evitar uma série de "questões CS desagradável".
Uma vez eu comecei a escrever uma versão massivamente bifurcada de aspnet_compiler.exe
última vez que trabalhou em uma empresa de web, mas foi amarrado com "trabalho real" e nunca terminei. Maior problema é as páginas ASPX:. Coisas MVC / Navalha você pode paralelizar o inferno fora, mas o ASPX parse / motor de compilação é de cerca de 20 níveis de profundidade de classes / métodos internos e privadas
Eu não tenho nenhum dicas quentes específicos para este compilador, mas quando eu tenho esse tipo de problema, eu corro ProcMon para ver o que o processo está a executar na máquina, e eu corro Wireshark para verificar que não é gastando idades sincronismo-out algum tipo de acesso de rede para uma máquina há muito esquecido, que é referenciada em algumas variáveis ??chave do registro ou meio ambiente.
Apenas meus 2 centavos.
Uma das coisas abrandar vistas ASP.NET pré-compilação significativamente é a opção de linha de comando -fixednames
para aspnet_compiler.exe
. Não usá-lo especialmente se você estiver em Navalha / MVC.
Ao publicar o aplicativo WEP do Visual Studio certifique-se de selecionar "Não se fundem", e não selecione "criar assembly separado" causa isso é o que faz com que o bloqueio global e atrasa as coisas.
Mais informações aqui https: // MSDN .microsoft.com / en-us / library / hh475319 (v = vs.110) .aspx