Why is aspnet_compiler.exe so slow (and can it be made any faster)?

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.

Tonytonya

Were you able to get the aspnet_compiler to compile a site any faster? The answer you accepted wasn't very helpful since it said to use a web app project, which you already were doing – Criticize

Answer 1

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.

Causal

What is now your pre-compilation time with this solution ? – Cozen

Answer 2

Switching to Roslyn compiler most likely will significantly improve precompile time. Here is a good article about it: https://devblogs.microsoft.com/aspnet/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications/.

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

Bergama

Yes, this is great. We simply installed Microsoft.CodeDom.Providers.DotNetCompilerPlatform package to our project and got views compilation almost twice faster. – Ludovick

@MariuszPawelski I have this installed but MVCBuildViews step still uses aspnet_compiler.exe for some reason. Is there a way to force the compiler to use Roslyn to pre compile views? Core Compile and the other steps use csc.exe which is the new Roslyn compiler. – Blacking

@Blacking The Microsoft.CodeDom.Providers.DotNetCompilerPlatform package is a drop-in replacement for the in-box providers and installing the package is all you should have to do to enable them and aspnet_compiler.exe is is simply a wrapper around the runtime compilation feature and doesn’t use msbuild in any way. It will only compile the portions of your application that would’ve been compiled at runtime by ASP.NET So if you use MVCBuildViews it still gonna use aspnet_compiler.exe. It's just using roslyn internally so it's faster. – Ludovick

@Blacking In the end I used RazorGenerator.MsBuild. Here is one tutorial for this. It build only razor views but it's much faster than just installing this DotNetCompilerPlatform package. I only had one problem with helpers that I solved. – Ludovick

dead link. 4char – Feodora

Answer 3

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.

Babb

Answer 4

I don't have any specific hot tips for this compiler, but when I have this sort of problem, I run ProcMon to see what the process is doing on the machine, and I run Wireshark to check that it isn't spending ages timing-out some network access to a long-forgotten machine which is referenced in some registry key or environment variable.

Balmoral

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

Macintyre

I downvoted this answer because it is incorrect. The "Merge options" are for aspnet_merge.exe which is a separate program from aspnet_compiler.exe which this question is asking about. The Merge settings do not influence aspnet_compiler.exe performance at all (and aspnet_merge.exe is run after aspnet_compiler.exe in a separate MSBuild step). – Mccall

@Mccall nope, here's a quote from the docs: "Do not merge - This setting does not run aspnet_merge.exe and does not use the -fixednames option of the aspnet_compiler.exe command." – Macintyre