views:

48

answers:

2

Does UserControls in asp.net degrades performance.

MasterPage has its own life cycle Page has its own life cycle and UserControls has its own life cycle.

UserControls helps to divide work load and are easily maintainable, but does UserControls down grades performance of asp.net application?

+3  A: 

I've never seen them decrease performance, unless you do something foolish like have each user control be responsible for it's own DB look-up, and then bind them in a Repeater or something like that. If you use common sense, they should not degrade performance noticeably.

If you're talking optimizing down to the processor cycle, however, I would guess they would not because of how everything gets compiled down to MSIL, and then to Machine code, so I would guess the compiler can sort it out and would treat a user control no differently than if you had all the constituent controls directly on the page.
Edit - added

This article argues for how they can actually improve performance. Interesting.

In addition to their reusability and flexibility, Web user controls can take advantage of the ASP.NET caching engine to implement what is referred to as “fragment caching.” Essentially, fragment caching allows a Web developer to control the HTML caching of individual controls on a page, including setting the duration and caching various versions of the control based on query string, control properties, browser type, and even custom strings. The ability to cache only portions of pages is powerful since a portion of a page will often access relatively static data stored in a relational database or accessed through an XML Web service, while other portions of the same page manipulate dynamic data. For these static portions, creating a Web user control and setting caching options greatly reduces the number of database round trips, thereby increasing performance. In most instances, using ASP.NET caching judiciously is the single biggest performance improvement that can be made.

Good question. Again, I learned something new. Thank you.

David Stratton
+3  A: 

no more nor less than any other control added to the page. Remember, EVERY server control you add to the page has that same life cycle all of its own.

Of course that's assuming that you (or some other developer) do not do something to ACTIVELY make it degrade performance (i.e. making it count to a billion every page_load won't help performance).


Edit

Okay, here's the thing.

First, you're asking for a yes/no response to a question whose answer is "it depends." And the answer is "it depends" because I don't know how said user control is getting tortured in its related code.

Second, I'm going to add more text here. Basically I'm going to repeat what I said in a four sentences up above in about 1,000 words. So....

If you take a brand new user control. Don't add any code to it in the CodeBehind. Don't drop any server controls on the ASPX side of things.

Then there will be no difference in how it affects performance than adding an Asp:Button or an ASP:Label to the designer will affect performance.

TO BE CLEAR: Until you add stuff to a user control, it is no more, nor less, impactive on a website's performance than any server-side control is.

Will there be an "impact" on performance? Technically, yes, but effectively, no.

And that is a very important distinction. Remember, every server side control makes a minute impact on performance. They're instantiated objects, and instantiated objects consume memory and resources. Of course that impact is negligible, and I would only considered that minuscule impact as "degradation" when you're adding hundreds of controls (server or user) to a page.

The USE of user controls is not where you need to be concerned.

Your concern needs to be in the IMPLEMENTATION of the user control.

It's when a programmer gets into that CodeBehind and starts doing stupid things to eat up memory and processor cycles that things start degrading. Alternatively, how the programmer implements the user control can improve the performance of a web application (as David stated here).


Edit 2

The question "in general whether it is good to use usercontrols versus not to do the same work" is not the question you're asking up above. If the task you're doing degrades performance it's not going to matter if your task is in a user control or not. Additionally, if it's a good idea depends on the project, the team, the scope, and maybe even design paradigms.

  • The answer to "in general, is there a performance degradation to using a user control" is "effectively no."
  • The answer to "in general, is it a good idea" is "it depends."
  • The answer to "in general, will a task be better in a UserControl or not" again, is "it depends."

Without details about your specific situation (code base, design, dev team, maintenance team, etc) there cannot be a better answer.

I've built applications where using a User Control was overkill and would have bloated the application unnecessarily. I've built applications where using a User Control was not precise enough and was actively hard on the back end [we were dynamically instantiating controls, so we used Custom and Composite Server Controls rather than user controls (all code, versus code + designer)]. And I've built applications where user controls were the perfect solution.

But all of those decisions were made due to design.

Stephen Wrighton
Can you summarize this and tell me in simple words whether it degrades performance or not? - Yes or No. If yes what exactly is causing that and if no what is the reasons.
Jordon
It's not really a simple yes/no question. The short answer is "Not in and of themselves" which is what both Stephen and I said in our answers. Programmers can do dumb things with them to MAKE them inefficient. Also, in my answer, you'll see how they can improve performance. His answer is pretty much as summarized as it gets.
David Stratton
In normal words can i believe you are also not sure?If you say its not simple Yes/No can you describe few important points, where you feel Yes and where you feel no?
Jordon
We both did that in our answers.
David Stratton
Jordon