ASP.NET application load time after some change

[Ravi Ambros Wallau]

Hi:
We developed a set of ASP.NET Web Applications that never runs in
stand-alone mode, but always inside a portal (Rainbow Portal). All modules
are copied on that portal.
My question is: load time takes, sometimes, three or four of minutes in
a medium-level machine (a PIII 1.5 Ghz), when the binary contents are
changed, or if the time of last modification of the web.config file is
changed.
An application that runs in "stand-alone" mode take no more than a few
seconds to be loaded after this kind of change.

What determines how much time will be spended on the process of loading
a page after some change? The number of DLL's in the bin folder, the
complexity of web.config file?
Is there some possible configuration in machine.config (or even
web.config) that can increase or decrease load time?
I suppose that a DLL compiled in DEBUG mode takes more time to load than
a DLL that was compiled in release mode. But this time is not the double or
the triple of the time spended in a release DLL, is it?

Thanks for your support. I am looking at google too, but I can't find
the right words to perform the search...

 

[Nathan Sokalski]

I am not an expert on calculating these things, but here are a few points to
keep in mind:

1. When the application uses multiple dll's, the server has more work to do,
therefore slightly increasing the time required
2. The server does cache some pieces of information, sometimes more
depending on the application. Therefore, this cache must be recreated if any
dll's or the web.config file is modified, increasing the time when the
application is run the first time.
3. The speed can also be affected by how much stuff is in viewstate. And
take note that if you have viewstate enabled for a large number of objects,
viewstate can become quite large after a couple postbacks of the same page.
Therefore, it is a good idea to remember to set viewstate to False for
anything reasonable, since it is set to True by default. Many controls such
as Labels or Controls who have their value set in the Load event have no
need for viewstate, when I saw the difference between my pages when I
started remembering to do this it was a big difference in efficiency.
4. Sometimes it is better not to use ASP.NET Controls. For example, if you
have an image that is "just there" and is always the same, just use a plain
HTML img tag for it, this is less code because it does not get declared as a
Control (even if you never reference a Control, Visual Studio .NET
automatically adds the declaration for WebControls, but it does not
automatically add declarations for HtmlControls), therefore creating less
work for the server.
5. Anywhere possible, use subprocedures and/or functions. Even if the
subprocedure/function is only used 2 or 3 times, it is less compiled code
because the compiler only needs to compile it once.

There may be other things you can do, but I am not sure what they might be.
Please don't be offended if I mentioned anything that sounds "common sense",
I remember how much I knew when I first started ASP.NET, and sometimes
simple things aren't simple until someone has told you about them. There are
things that I spent almost a year doing the hard way because I didn't know
there was a better way. Good Luck!

 

[Ravi Ambros Wallau]

Nathan:
Thanks for your response.
I believe that's the problem is the large number of DLL's that I have on
my bin folder...
There's nothing else that I can do... Probally .Net indexes all DLL's
before loading the application. Tks

I am not an expert on calculating these things, but here are a few points
to keep in mind:

1. When the application uses multiple dll's, the server has more work to
do, therefore slightly increasing the time required
2. The server does cache some pieces of information, sometimes more
depending on the application. Therefore, this cache must be recreated if
any dll's or the web.config file is modified, increasing the time when the
application is run the first time.
3. The speed can also be affected by how much stuff is in viewstate. And
take note that if you have viewstate enabled for a large number of
objects, viewstate can become quite large after a couple postbacks of the
same page. Therefore, it is a good idea to remember to set viewstate to
False for anything reasonable, since it is set to True by default. Many
controls such as Labels or Controls who have their value set in the Load
event have no need for viewstate, when I saw the difference between my
pages when I started remembering to do this it was a big difference in
efficiency.
4. Sometimes it is better not to use ASP.NET Controls. For example, if you
have an image that is "just there" and is always the same, just use a
plain HTML img tag for it, this is less code because it does not get
declared as a Control (even if you never reference a Control, Visual
Studio .NET automatically adds the declaration for WebControls, but it
does not automatically add declarations for HtmlControls), therefore
creating less work for the server.
5. Anywhere possible, use subprocedures and/or functions. Even if the
subprocedure/function is only used 2 or 3 times, it is less compiled code
because the compiler only needs to compile it once.

There may be other things you can do, but I am not sure what they might
be. Please don't be offended if I mentioned anything that sounds "common
sense", I remember how much I knew when I first started ASP.NET, and
sometimes simple things aren't simple until someone has told you about
them. There are things that I spent almost a year doing the hard way
because I didn't know there was a better way. Good Luck!

 

[Nathan Sokalski]

I am not sure if it will actually speed up your application, but if you have
*.dll's that you rarely or never modify/replace (perhaps dll's from
third-parties, such as Oracle's database dll), you can try out a utility
called ILMerge. This utility combines multiple .NET dll's into one dll file.
I have never actually used it, because I have never had the opportunity to
write an application that uses more than one dll, but it sounds nice and for
some people quite useful. Here is the URL to download it:

http://www.microsoft.com/downloads/...87-b4ad-4eae-87cf-b14ae6a939b0&displaylang=en

I think I mentioned all my other ideas, so if your application really seems
too slow and your server is working correctly, you may want to try to work
on improving code efficiency (please don't take that as an insult, almost
any code can be improved in some way or another, even that written by the
best). Anyway, Good Luck!
--
Nathan Sokalski
(e-mail address removed)
http://www.nathansokalski.com/

Nathan:
Thanks for your response.
I believe that's the problem is the large number of DLL's that I have
on my bin folder...
There's nothing else that I can do... Probally .Net indexes all DLL's
before loading the application. Tks

 

[Ravi Ambros Wallau]

Thanks for your support, and I'm not offended... As an experienced
programmer, I know exactly what you are talking about...
I've made some testes and have some interesting results:
- After modifying web.config file, load time of first page takes about 15
seconds...
- If I only run iisreset.exe, load time is about 4 or 5 seconds...
- If I run iisreset.exe _and_ delete the contents of Temporary ASP.NET
Files, load time is about 16 seconds...

But what took my atention is that ASP.NET makes a copy of all DLL's in a
folder 770de4ce\9a480d92\assembly\dll2, each DLL with it's own directory
(and a AssemblyInfo.ini file)...
I don't know why this happens... It's not a good behavior for me, but I
think it's related with some "never stop the server" feature...
I think that create 370 directories and copy 370 files (and create 370
ini's) is a heavy thing to do...

I'll use ILMerge and test to see what happens...
Thanks!

I've note