【问题标题】:Why is aspnet_compiler.exe so slow (and can it be made any faster)?为什么 aspnet_compiler.exe 这么慢(并且可以做得更快)?
【发布时间】:2010-09-22 08:02:26
【问题描述】:

在我们的构建过程中,我们对我们的网站运行 aspnet_compiler.exe 以确保 ASP.NET/MVC 中的所有后期绑定的东西都实际构建(我对 ASP.NET 一无所知,但我确信这是防止发现运行时的故障)。

我们的网站规模相当大,有几百个页面/视图/控件/等。但是,在 10-15 分钟的范围内花费的时间似乎过多(作为参考,这比编译大约 40 个项目的整个解决方案所需的时间要长,而且我们只预编译了两个网站项目)。

我怀疑硬件是问题,因为我在最新的四核 Intel 芯片上运行,配备 4GB RAM 和 WD Velociraptor 10,000rpm 硬盘。奇怪的是,EXE 似乎并没有使用太多 CPU (1-5%),而且似乎也没有做太多的 I/O。

那么...这是一个已知问题吗?为什么这么慢?有什么办法可以加快速度?

注意:为了澄清人们已经回答的几件事,我不是在谈论 Visual Studio 中的代码编译。我们已经在使用 Web 应用程序项目,编译速度不是问题。问题是站点的预编译在这些项目已经被编译 (see this MSDN page for more details) 作为开发构建脚本的一部分。我们正在执行就地预编译,而不是将文件复制到目标目录。

【问题讨论】:

  • 您是否能够让 aspnet_compiler 更快地编译站点?您接受的答案不是很有帮助,因为它说要使用您已经在做的网络应用项目

标签: asp.net aspnet-compiler pre-compilation


【解决方案1】:

我对此编译器没有任何具体的热点提示,但是当我遇到此类问题时,我会运行 ProcMon 来查看进程在机器上执行的操作,然后运行 ​​Wireshark 来检查它是否不是花费很长时间来超时对某些注册表项或环境变量中引用的长期被遗忘的机器进行一些网络访问。

【讨论】:

    【解决方案2】:
    1. 编译器应该为每个 .aspx 页面生成第二个代码隐藏文件,check
    2. 在编译期间,aspnet_compiler.exe 会将所有网站文件复制到输出目录,包括 css、js 和图像。

    使用Web application project 而不是网站模型,您将获得更好的编译时间。

    【讨论】:

    • 您现在使用此解决方案的预编译时间是多少?
    【解决方案3】:

    简单地说,aspnet_compiler 在开始预编译任何单独的 aspx 页面时使用实际上是“全局编译器锁”;基本上只允许按顺序编译每一页。

    这是有原因的(尽管我个人不同意) - 主要是为了检测和防止循环引用导致各种无限循环,以及确保在编译所需页面之前正确构建所有依赖项,他们避免了很多“讨厌的 CS 问题”。

    上次我在一家网络公司工作时,我曾经开始编写 aspnet_compiler.exe 的大规模分支版本,但被“真正的工作”所束缚,从未完成。最大的问题是 ASPX 页面:您可以将 MVC/Razor 的东西并行化出地狱,但 ASPX 解析/编译引擎的内部和私有类/方法大约有 20 级深度。

    【讨论】:

      【解决方案4】:

      切换到 Roslyn 编译器很可能会显着缩短预编译时间。这是一篇关于它的好文章:https://devblogs.microsoft.com/aspnet/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications/。

      除此之外,通过在编译元素上将批处理属性设置为 true 来确保启用批处理编译。

      【讨论】:

      • 是的,这很棒。我们只需将Microsoft.CodeDom.Providers.DotNetCompilerPlatform 包安装到我们的项目中,视图编译速度几乎快了两倍。
      • @MariuszPawelski 我已经安装了这个,但由于某种原因,MVCBuildViews 步骤仍然使用 aspnet_compiler.exe。有没有办法强制编译器使用 Roslyn 来预编译视图?核心编译和其他步骤使用 csc.exe,它是新的 Roslyn 编译器。
      • @delloPiro Microsoft.CodeDom.Providers.DotNetCompilerPlatform 软件包是内置提供程序的直接替代品,您只需安装该软件包即可启用它们和 aspnet_compiler .exe 是 只是运行时编译功能的包装器,不以任何方式使用 msbuild。它只会编译在运行时由 ASP.NET 编译的应用程序部分所以如果你使用 MVCBuildViews 它仍然会使用 aspnet_compiler.exe。它只是在内部使用 roslyn,所以速度更快。
      • @delloPiro 最后我使用了RazorGenerator.MsBuild。这是一个tutorial。它仅构建剃刀视图,但比仅安装此 DotNetCompilerPlatform 包要快得多。我在solved 的助手方面只有一个问题。
      • 死链接。 4个字符
      【解决方案5】:

      只要我的 2 美分。

      显着减慢 ASP.NET 视图预编译的原因之一是 aspnet_compiler.exe 的 -fixednames 命令行选项。 不要使用它,尤其是在使用 Razor/MVC 时。

      从 Visual Studio 发布 wep 应用程序时,请确保选择“不合并”,并且不要选择“创建单独的程序集”,因为这是导致全局锁定并减慢速度的原因。

      更多信息在这里https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx

      【讨论】:

      • 我否决了这个答案,因为它不正确。 “合并选项”适用于 aspnet_merge.exe,它是与此问题所问的 aspnet_compiler.exe 不同的程序。 Merge 设置根本不影响aspnet_compiler.exe 的性能(并且aspnet_merge.exe 在单独的MSBuild 步骤中在aspnet_compiler.exe 之后运行)。
      • @Dai 不,这是来自文档的引用:“不要合并 - 此设置不运行 aspnet_merge.exe 并且不使用 aspnet_compiler.exe 命令的 -fixednames 选项。 "
      猜你喜欢
      • 2017-02-18
      • 1970-01-01
      • 2011-04-22
      • 2023-04-11
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多