Does UserControls in asp.net degrades performance.
asp.net中的UserControls是否会降低性能。
MasterPage has its own life cycle Page has its own life cycle and UserControls has its own life cycle.
MasterPage有自己的生命周期页面有自己的生命周期,UserControls有自己的生命周期。
UserControls helps to divide work load and are easily maintainable, but does UserControls down grades performance of asp.net application?
UserControls有助于分担工作量并且易于维护,但UserControls会降低asp.net应用程序的等级性能吗?
2 个解决方案
#1
6
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.
我从来没有见过它们会降低性能,除非你做一些愚蠢的事情,比如让每个用户控件负责它自己的DB查找,然后将它们绑在Repeater或类似的东西中。如果你使用常识,它们不应该明显降低性能。
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
但是,如果你正在谈论优化到处理器周期,我猜他们不会因为一切都被编译成MSIL,然后编译到机器代码,所以我猜想编译器可以对它进行排序并对待它用户控件与您直接在页面上拥有所有组成控件的方式没有什么不同。编辑 - 添加
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.
除了可重用性和灵活性之外,Web用户控件还可以利用ASP.NET缓存引擎来实现所谓的“片段缓存”。基本上,片段缓存允许Web开发人员控制各个控件的HTML缓存。一个页面,包括根据查询字符串,控件属性,浏览器类型甚至自定义字符串设置持续时间和缓存控件的各种版本。仅缓存部分页面的能力是强大的,因为页面的一部分通常将访问存储在关系数据库中或通过XML Web服务访问的相对静态数据,而同一页面的其他部分操纵动态数据。对于这些静态部分,创建Web用户控件和设置缓存选项可以大大减少数据库往返次数,从而提高性能。在大多数情况下,明智地使用ASP.NET缓存是可以实现的单一最大性能改进。
Good question. Again, I learned something new. Thank you.
好问题。我又一次学到了新东西。谢谢。
#2
3
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).
当然,这是假设你(或其他一些开发人员)没有做任何事情来使它降低性能(即每个page_load数十亿都不会有助于提高性能)。
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....
其次,我将在这里添加更多文字。基本上我会用大约1000个单词重复我上面用四句话说的话。所以....
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.
如果你采取全新的用户控制。不要在CodeBehind中添加任何代码。不要在ASPX端丢弃任何服务器控件。
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.
然后,与添加Asp:Button或ASP相比,它对性能的影响没有区别:设计师的标签会影响性能。
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).
当程序员进入CodeBehind并开始做愚蠢的事情以消耗内存和处理器周期时,事情开始降级。或者,程序员如何实现用户控件可以提高Web应用程序的性能(正如David在此处所述)。
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."
“通常,使用用户控件会导致性能下降”的答案是“实际上没有”。
“一般来说,这是一个好主意”的答案是“它取决于”。
“一般来说,在UserControl中的任务是否会更好”的答案是“它取决于”。
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.
但所有这些决定都是出于设计原因。
#1
6
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.
我从来没有见过它们会降低性能,除非你做一些愚蠢的事情,比如让每个用户控件负责它自己的DB查找,然后将它们绑在Repeater或类似的东西中。如果你使用常识,它们不应该明显降低性能。
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
但是,如果你正在谈论优化到处理器周期,我猜他们不会因为一切都被编译成MSIL,然后编译到机器代码,所以我猜想编译器可以对它进行排序并对待它用户控件与您直接在页面上拥有所有组成控件的方式没有什么不同。编辑 - 添加
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.
除了可重用性和灵活性之外,Web用户控件还可以利用ASP.NET缓存引擎来实现所谓的“片段缓存”。基本上,片段缓存允许Web开发人员控制各个控件的HTML缓存。一个页面,包括根据查询字符串,控件属性,浏览器类型甚至自定义字符串设置持续时间和缓存控件的各种版本。仅缓存部分页面的能力是强大的,因为页面的一部分通常将访问存储在关系数据库中或通过XML Web服务访问的相对静态数据,而同一页面的其他部分操纵动态数据。对于这些静态部分,创建Web用户控件和设置缓存选项可以大大减少数据库往返次数,从而提高性能。在大多数情况下,明智地使用ASP.NET缓存是可以实现的单一最大性能改进。
Good question. Again, I learned something new. Thank you.
好问题。我又一次学到了新东西。谢谢。
#2
3
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).
当然,这是假设你(或其他一些开发人员)没有做任何事情来使它降低性能(即每个page_load数十亿都不会有助于提高性能)。
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....
其次,我将在这里添加更多文字。基本上我会用大约1000个单词重复我上面用四句话说的话。所以....
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.
如果你采取全新的用户控制。不要在CodeBehind中添加任何代码。不要在ASPX端丢弃任何服务器控件。
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.
然后,与添加Asp:Button或ASP相比,它对性能的影响没有区别:设计师的标签会影响性能。
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).
当程序员进入CodeBehind并开始做愚蠢的事情以消耗内存和处理器周期时,事情开始降级。或者,程序员如何实现用户控件可以提高Web应用程序的性能(正如David在此处所述)。
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."
“通常,使用用户控件会导致性能下降”的答案是“实际上没有”。
“一般来说,这是一个好主意”的答案是“它取决于”。
“一般来说,在UserControl中的任务是否会更好”的答案是“它取决于”。
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.
但所有这些决定都是出于设计原因。