Batch compilation will be disabled even if the batch attribute is true in the <compilation> element.

This attribute is found in your machine.config (in ASP.NET 1.1) in the compilation element as you can see below. By default, the batch attribute is set to true, but this is something which gets overridden by debug=true. This means that even if the batch is set to true, debug=true does not let the compiler do batch compilation!!! Instead, each aspx file ends up with a separate assembly as you saw in Figure 6.

Listing 4

<!-- compilation Attributes:
   tempDirectory="directory"
   debug="[true|false]"    // Default: false
   strict="[true|false]"   // Default: false
   explicit="[true|false]" // Default: false
   batch="[true|false]"    // Default: true
   batchTimeout="timeout in seconds" // Default: 15 seconds
   maxBatchSize="max number of pages per batched compilation" 
  // Default: 1000 classes
   maxBatchGeneratedFileSize="max combined size (in KB) of the generated source
   files per batched compilation" Default: 3000KB
   numRecompilesBeforeAppRestart="max number of recompilations before appdomain
   is cycled" Default: 15 recompilations
   defaultLanguage="name of a language as specified in a <compiler/> tag below" 
  // Default: VB
 -->

What does all this mean in plain English?

Well, you might have already noticed that the first time you access any page in your asp.net application, it renders a bit slowly. When you access the same page again it is blazingly fast. Now, if you access another page from the same folder you see that this page will come up fast as well. The delay is due to JIT compilation, but why do you other pages render fast? It happens because the first access to any page in the same folder compiles all the pages of that folder into one assembly. The maxBatchSize attribute is set to 1000 classes by default and this means that if there are 1001 classes, you will see just 2 DLL's being created and the first 1000 classes will go into the first DLL and so on. BUT, this happens ONLY when debug=false. When debug=true the output is something like you saw in Listing 6. Thus, if you have 1001 classes and debug=true, you will see 1001 DLL's sprayed all over your memory. This cannot be good for the worker process health. In fact, this tends to fragment the memory very badly until you start seeing Out of Memory exceptions. If you want to verify how these files get compiled into one assembly, have a look at them in ILDASM.exe.

For this sample Global.asax is compiled into 1 DLL; all the other files in the root folder are compiled into one and all the files in SomeFolder folder in another for a total of 3 assemblies!

Figure 8 – ILDasm output showing all the batch compiled pages with Debug=False