To include or not to include?

By Michiel van Otegem
1 March 2001

Include files have many benefits. They provide us with a means of reusing code in different ways. We can put HTML or ASP code in an include file and include it in a page at the point we want the HTML to be shown or the ASP to be run. In addition we can create functions and even classes in an include file. We can call this code from any page including the file that contains these functions and classes. Although these features are very handy, they can have drawbacks. We need to look a little more at the internals of ASP to see them...

ASP under the hood

To improve performance ASP actually compiles scripts and stores them in a memory cache. If a script is called again, it is run from the cache, instead of being reloaded and re-interpreted. The benefits to the performance are enormous. You can see this when you time a script's execution time (see How fast is my code?). The second time you run your script, the overhead of the compilation is gone and it will run much faster.

The ASP cache is not limitless. IIS 5.0 caches 250 scripts by default and kicks out a script to make room for the 251th script. This setting can be changed under Script File Cache in Home directory - Configuration - Process Options in the WWW Service Master properties (MMC). IIS 4.0 by default does allow a limitless number of scripts to be cached, but that would eventually criple the server as the physical memory has it's bounds. This is also where our problem with includes arises...

Files are included before any ASP code is run. This means that files are included, whether we use them or not. In addition ASP caches the compiled result of a page, including all the include files. Another page using the same include can not benefit from the include file that was compiled for another page. Hence the include file is compiled and cached for each script using it. This also goes for files that are included more than once in one page.

So... what should I do?

Obviously you should avoid large include files with a lot of code that only gets executed in some pages that include the file. Also try avoiding nested includes and multiple includes. In essence know what goes on when you do something.

Alternative 1: Server.Execute
If you are using ASP 3.0 (Windows 2000/IIS 5.0), then you can make use of Server.Execute. It runs the specified ASP file as is at the point you call it. All intrinsic ASP objects (Request, Response, etc.) are available in the called ASP file. Once the file has been completely executed, control comes back to the calling page. The advantage is that the called file is only cached once, even if multiple pages call it.

A drawback of the Server.Execute method is that the script that is called is cached on it's own. If the server has (been set to) a limited number of cached scripts, this may be a valuable spot. So like with includes, this should be used wisely. In some cases Server.Execute and include are interchangeable. You can then test both cases under load and see which performs better.

Another drawback of the Server.Execute method is that we can't call functions inside the code. It just runs the code inside. The only way we can get around this is by using the Session object as a stack to save parameters on and get the parameters from the stack in the file being called. We can use the same technique to return values.

Alternative 2: Create components
If you're serious about reusing code, then creating a component may be the way to go. As with the include files it allows you to call functions that perform a certain function. The result can either be dumped straight into the result stream by the component, or by ASP.

Components are pre-compiled and therefore run faster than script code, always. There is is some overhead involved however in invoking them, so small code blocks do not qualify for this approach. Then again we don't get real problems with include files unless we are talking about large blocks of code.

A final piece of advice

What has been discussed above is a guideline to help you decide what is best in your case. If you have a machine with 256 Mb of RAM (or more), you will likely not get in to trouble easily. Also every case is different. If you have opportunity, you may want to test the different scenario's.