当前位置:  开发笔记 > 后端 > 正文

为什么aspnet_compiler.exe这么慢(可以更快)?

如何解决《为什么aspnet_compiler.exe这么慢(可以更快)?》经验,为你挑选了2个好方法。

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

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

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

那么......这是一个众所周知的问题吗?为什么这么慢?有没有办法加快速度?

注意:为了澄清人们已经回答的一些事情,我不是在谈论Visual Studio中的代码编译.我们已经在使用Web应用程序项目了,编译速度不是问题.问题是在已经编译这些项目之后预先编译网站(有关详细信息,请参阅此MSDN页面)作为开发构建脚本的一部分.我们正在执行就地预编译,而不是将文件复制到目标目录.



1> 小智..:

切换到Roslyn编译器很可能会显着改善预编译时间.这是一篇很好的文章:http://blogs.msdn.com/b/webdev/archive/2014/05/12/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications. aspx.

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



2> JerKimball..:

简单地说,aspnet_compiler只要它开始预编译任何单独的aspx页面,就会使用有效的"全局编译器锁定"; 它基本上只允许按顺序编译每个页面.

这是有原因的(虽然我个人不同意) - 主要是为了检测和防止导致无限循环排序的循环引用,以及确保在编译需求页​​面之前正确构建所有依赖项,它们避免很多"令人讨厌的CS问题".

我曾经开始写一个大量分叉的版本,aspnet_compiler.exe上次我在一家网络公司工作,但却被"真正的工作"所束缚,从未完成它.最大的问题是ASPX页面:你可以将HELL并行化的MVC/Razor,但是ASPX解析/编译引擎大约是内部和私有类/方法的20级.

推荐阅读
地之南_816
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有