Article for beginners

An area of concern regarding download time is when using ASP includes. Includes are used to call large amounts of content that would be unwieldy in the primary file or files that are going to be displayed on many or all pages in a site. An example is the basic structure of the site. An index file could – for example – call included files such as header, footer, buttons and contents.

The first three are components that will show on every page of the site, while the last calls specific content based on variables. Include files are used to ease site maintenance of and to simplify site structure. Deciding if an area needs an include is a matter of judgment, and varies from page to page. If an area has several sub-sections, it could be useful to place all those into an include file and call those from the index file. It might make more sense to call them through a contents.inc file (such as the contents that are being displayed to you in this page).

During the initial pass through an ASP page, the server will check through every reference to included files and store them in the server’s cache. Even if there is a reference to an included file that occurs inside an IF or SELECT statement – regardless if the IF statement returns true or false or if a specific case is selected – the server validates the existence of the file, the code contained within, and stores it in the server’s cache. It doesn’t matter if the contents within the include are utilized or not – if a page has poorly utilized includes, this evaluation can significantly slow the server in processing the code, which in turn adds download time.

The rule of thumb here is to use includes efficiently, and as a general rule, minimize the use of nested include files (i.e., an include within another include,) wherever possible. It used to be that the practice of using nested includes would generate errors. While this is seldom the case now, it does make it much harder to track down an offending file when errors do occur, or when material needs to be changed.

Every ASP developer needs to be aware of ALL the objects that he or she instantiates in their code. Typically, when a developer creates an object in ASP, the server will ‘pool’ the object, and it will remain in the server’s cache until the ASP session ends. If the object is not used again, it will be an inefficient use of the server, its memory, and its processor. A good stylistic rule of thumb in ASP programming is to indent the code for each object created, so the developer can easily recognize when and where an object has been created and where it needs to be destroyed after its use.

For variables a similar rule applies – declare ASP variables explicitly by stating ‘Option Explicit’ at the top of the ASP page. This way, the memory used for the variables will be used in the most efficient way possible. If you are successful in applying these guidelines consistently, your server will love you in the end!

Popularity: 13% [?]