controls and performance ...

[Ashish]

hi all,
Iam trying to investigate some serious memory problems and ways to
optimize them in our web application.

some of the information i collected using the performance monitor, is
that number of assemblies loaded per appdomain is large,
we have a lot of pages which are using number of user controls,
some of the documentation i read in this respect was that when asp.net
will compile the page ( first time it is accessed) it will create an
assembly for each page , and if that page references user controls,
assemblies would be created for each user control too

I dont know how much iam correct on this

this would load a large amount of assemblies and assemblies would not be
unloaded untill the appdomain gets unlaoded from asp.net wp

some articles on monitoring and performance also say that avoid using
<%@reference .. > , <@%import ... > or <@%register > directives as these
would create parse time dependencies, and use LoadControl instead, in
all the examples online to use usercontrols, even though we can use
loadcontrol, we still need to <@%register > directive to strong type
casting

can anyone throw more light on this, and may be tell me if my
investigation is going in right direction or not,

any help/pointers would be appreciated

Regards
-ashish

 

[David Ebbo [MSFT]]

Hi Ashish,

This is not exactly correct. Whenever possible, ASP.NET will batch compile
multiple pages and user controls together, hence creating a smaller number
of assemblies that need to be loaded. Note that this does not happen if
the page/uc has a debug=true attribute. Maybe that is whay you are seeing
this?

As for the suggestion about avoiding <%@reference .. > , <@%import ... > or
<@%register >, it is not quite correct, except for one case: if you have
<%@ import src="somefile.cs" %> that file is always compiled by itself.
But for loading user control, it makes no difference whether you use
@register or LoadControl when it comes to the number of assemblies that get
loaded.

Hope this helps,
David;

 

[Ashish]

Hi Ashish,

This is not exactly correct. Whenever possible, ASP.NET will batch compile
multiple pages and user controls together, hence creating a smaller number
of assemblies that need to be loaded. Note that this does not happen if
the page/uc has a debug=true attribute. Maybe that is whay you are seeing
this?

As for the suggestion about avoiding <%@reference .. > , <@%import ... > or
<@%register >, it is not quite correct, except for one case: if you have
<%@ import src="somefile.cs" %> that file is always compiled by itself.
But for loading user control, it makes no difference whether you use
@register or LoadControl when it comes to the number of assemblies that get
loaded.

Hope this helps,
David;

Thanks David,
after so many days i thought no one would reply,
i was also wondering that if some controls were conditional on the page
i.e if there was a control which is embedded inside another control, and
the container control is being haevily used, but embedded conntrol is
used only in 10 % of the sitiuations, would conditional loading help
reducing amount of objects being created ?

TIA
-ashish

 

[David Ebbo [MSFT]]

Yes, absolutely. If you conditionally load some controls, then you will
indeed reduce the number of objects in the tree for requests where those
conditional controls are not needed.

David;

--

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this
message are best directed to the newsgroup/thread from which they
originated.