views:

545

answers:

2

I'm using aspnet_compiler.exe to precompile my application for deployment.

However, I don't think it's working, for two reasons:

  • I see my applications assemblies under C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files, even if i manually clear out this directory & restart the app.
  • The performance hit to JIT the application is present. This is very specifically what I'd like to avoid, even though it is 'one time'.

Here's specifically what I'm doing:

  1. Build the solution in studio.
  2. execute aspnet_compiler.exe -v /Foo -p c:\builddir c:\deploydir (where Foo is the vdir my app runs under, c:\builddir is where studio builds to, and c:\deploydir is the location where
  3. I then copy c:\deploydir to the web server.
  4. I access http://localhost/Foo
  5. After 30 seconds, the app displays, and I can see that assemblies have been generated in Temporary ASP.NET Files.

If it's notable, I'm using .net 3.5 SP1/Studio 2008 SP1. compilation debug=false is also set in web.config.

+1  A: 

Precompiling the website with aspnet_compiler.exe doesn't JIT compile the code - you would need to ngen the code to do that.

The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead using the just-in-time (JIT) compiler to compile the original assembly.

Andrew Hare
As much as I would like it to, ngen apparently does not apply to asp.net. http://support.microsoft.com/kb/331979
JohnW
That KB article applies to ASP.Net 1.0 and 1.1
Stuart Dunkeld
That article only applies to ASP.NET 1.x - NGEN'd assemblies have been supported since 2.0 - please see http://msdn.microsoft.com/en-us/magazine/cc163808.aspx
Andrew Hare
Thank you both. I think I may see the solution now - precompile the website for deployment, using fixed names, deploy the solution to the server, and then ngen all assemblies in bin.
JohnW
JohnW: NGENing doesn't always improve performance. It might actually reduce it. Always benchmark.
Mehrdad Afshari
@JohnW: Mehrdad is correct - NGENing the assembly only removes the need for jitting the IL. Since the JIT tends to be more efficient than NGENing you really ought to benchmark,
Andrew Hare
+2  A: 

Your two points are moot:

  1. ASP.NET precompilation doesn't result in native image generation so JIT overhead will still be there. There might be a worker process creation overhead too.

  2. ASP.NET precompilation has the option to compile everything (incl. ASPX stuff, ...) or just source code (which you can specify with the -u switch). In case of the latter, those assemblies will still be generated for ASPX files. In case of the former, what you are seeing is not assembly generation. The runtime just copies and caches the assemblies in /bin in Temporary ASP.NET Files. You can confirm this fact by comparing the assemblies byte by byte and see that they are identical.

Mehrdad Afshari
I'm trying to reconcile your response for #1 (which seems logical to me) with msdn.microsoft.com/en-us/library/…, which states, "Precompiling an ASP.NET Web site provides faster initial response time for users since pages do not have to be compiled the first time they are requested. This is particularly useful for large Web sites that are updated frequently." #2 is N/A given my sample above.
JohnW
Being faster is relative. It's faster than non-precompiled apps not for preventing JIT compilation but for not invoking the ASPX parser and C# compiler.
Mehrdad Afshari
Oops... http://msdn.microsoft.com/en-us/library/ms227972.aspx was the reference URL.
JohnW
Interesting. So what you're saying is that I'm not incurring the hit to generate the MSIL for the site, but I am incurring the hit to go from MSIL to x86. Thanks, this makes sense.
JohnW