为什么aspnet_compiler.exe这么慢（可以更快）？

Question

During our build process we run aspnet_compiler.exe against our websites to make sure that all the late-bound stuff in ASP.NET/MVC actually builds (I know nothing about ASP.NET but am assured this is necessary to prevent finding the failures at runtime).

Our sites are fairly large in size, with a few hundred pages/views/controls/etc. however the time taken seems excessive in the 10-15 minute range (for reference, this is longer than it takes the entire solution with approx 40 projects to compile, and we're only pre-compiling two website projects).

I doubt that hardware is the issue as I'm running on the latest Quad core Intel chip, with 4GB RAM and a WD Velociraptor 10,000rpm hard disk. And part of what's odd is that the EXE doesn't seem to be using much CPU (1-5%) and doesn't seem to be doing an awful lot of I/O either.

So... is this a known issue? Why is it so slow? And is there any way to speed it up?

Note: To clarify a couple of things people have answered about, I am not talking about the compilation of code within Visual Studio. We're using web application projects already, and the speed of compilation of those is not the issue. The problem is the pre-compilation of the site after these projects have already been compiled ( see this MSDN page for more details ) as part of the dev build script. We are performing in-place pre-compilation, not copying the files to a target directory.

Answer 1

Switching to Roslyn compiler most likely will significantly improve precompile time. Here is a good article about it: http://blogs.msdn.com/b/webdev/archive/2014/05/12/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications.aspx .

In addition to this, make sure that batch compilation is enabled by setting batch attribute to true on the compilation element.

Answer 2

Simply, the aspnet_compiler uses what is effectively a "global compiler lock" whenever it starts pre-compiling any individual aspx page; it is basically only allowed to compile each page sequentially.

There are reasons for this (although I personally disagree with them) - primarily, in order to detect and prevent circular references causing an infinite loop of sorts, as well as ensuring that all dependencies are properly built before the requiring page is compiled, they avoid a lot of "nasty CS issues".

I once started writing a massively-forked version of aspnet_compiler.exe last time I worked at a web company, but got tied up with "real work" and never finished it. Biggest problem is the ASPX pages: the MVC/Razor stuff you can parallelize the HELL out of, but the ASPX parse/compile engine is about 20 levels deep of internal and private classes/methods.

Answer 3

1. Compiler should generate second code-behind file for every .aspx page, check
2. During compilation, aspnet_compiler.exe will copy ALL of the web site files to the output directory, including css, js and images.

You'll get better compilation times using Web application project instead of Web site model.

Answer 4

我没有针对这个编译器的任何特定热门技巧，但是当我遇到这种问题时，我运行ProcMon来查看该进程在机器上正在做什么，并且我运行Wireshark来检查它是否花费了很多时间 - 对某个注册表项或环境变量中引用的长时间遗忘的计算机的某些网络访问。

Answer 5

Just my 2 cents.

One of the things slowing down ASP.NET views precompilation significantly is the -fixednames command line option for aspnet_compiler.exe . Do not use it especially if you're on Razor/MVC.

When publishing the wep app from Visual Studio make sure you select "Do not merge", and do not select "create separate assembly" cause this is what causes the global lock and slows things down.

More info here https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx