I don't think it has something to do with the number of #include but rather the amount of parsing the IIS has to do.<BR><BR>Of course a large #include it probably better than a lot of smaller #include(s).
Depends on the nature of the .asp<BR>iis compiles the page requested. example: <BR>default.asp<BR> includes settings.asp<BR><BR>then settings.asp is compiled inside default.asp<BR><BR>later the following situation occures<BR>mail.asp<BR> includes settings.asp<BR><BR>settings asp is (again) compiled inside mail.asp.<BR><BR>This might not be a problem, exept for the situation that there are many include files with several functions. Making 1 big asp of the include (might) speed up the execution of one page, but that big .asp is also completly included inside another .asp file which also includes that file while it only needs 1 proc of that total file! Here is the problem, many LARGE pages are cached inside of the ram of the server and it cripples...<BR><BR>so i think it might be wiser to include more smaller files with each a specific function but to limit the includes done on a page, so the second page only has to include a small file and the sysop of the webserver hasn't to run to the store to buy more ram...<BR><BR>btw. if the server HAS enough ram the server will cache the page so that the include doesn't have to be performed again... so the speed difference will only be there the first request of the page (if all goes well ;-)