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
