在 MVC3 页面中包含 RenderPartial 的开销是多少
我正在尝试尽可能优化我的代码。我使用了很多像这样的部分文件：
@if (Model.PageMeta.Sidebar == PageMetaSidebar.Small) { Html.RenderPartial("_SmallSidebar"); }
..
..
..
有人可以告诉我这是否会带来性能开销。据我所知，Razor 视图是经过编译的。当页面显示时，是否会读取另一个磁盘以获取我使用的每个部分文件的数据。如果是这种情况，那么我的布局页面上的例如 5 个 RenderPartials 会带来多少额外开销。
I am trying to optimize my code as much as possible. I use a lot of partial files like this:
@if (Model.PageMeta.Sidebar == PageMetaSidebar.Small) { Html.RenderPartial("_SmallSidebar"); }
..
..
..
Can someone tell me if there is a performance overhead with this. I understand that Razor views are compiled. Is it the case that when the page is displays there is another disk read to get the data for each of the partial files that I use. If that's the case then how much additional overhead could I expect with for example 5 RenderPartials on my layout page.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这里不会有明显的性能影响，因为在将生成的 HTML 流回浏览器之前，部分内容只是被拉入 asp.net Web 服务器。这并不是一个昂贵的磁盘读取操作，并且不会比单个 cshtml 慢。显然，如果在许多视图中重复使用相同的局部视图，则应该使用局部视图。如果仅在单个视图中使用，那么只需将其拆分为单独的部分以将模型的各个部分分离到不同的视图中就可以了。
请注意，您也可以只使用：
而不是使用 RenderPartial 。这将在本地视图文件夹中查找，如果找不到，则在共享文件夹中查找。
There will be no noticable performance hit at all here as the partials are just pulled in on the asp.net web server before streaming the resultant HTML back to the browser. This is not an expensive disk read to do and won't appear any slower than if it was a single cshtml. Obviously partials should be used if the same partial view is reused in many views. If only used in a single view then it's just a matter of clarity splitting it into a separate partials to separate parts of your model into different views.
Note you can also just use:
rather than using
RenderPartial. This will look in the local view folder then in shared if not found.我认为使用 RenderPartial 大约 5 次不会产生足够大的影响来设计糟糕的页面。如果拉出逻辑有意义（使页面更干净，由多个视图使用等），那么就这样做。如果您发现重大的性能问题，那么您应该当时查看它们，但不要过早地优化并创建糟糕的设计，因为您认为这可能会减慢速度。
I don't think using RenderPartial ~5 times is going to have a significant enough impact to design your pages poorly. If it makes sense to pull the logic out (makes the page cleaner, used by multiple views, etc.) then do it. If you notice significant performance issues then you should look at them at that time, but don't prematurely optimize and create a poor design because you THINK it might slow something down.
如果您想更好地了解潜在的性能影响，您可能需要使用 mvc-mini-profiler。
请注意，我并不提倡过早优化。但是，使用分析工具可能会让您更好地了解潜在的瓶颈，从而帮助您在将来避免它们。
If you like to get a better understanding of potential performance hits you might want to play around with the mvc-mini-profiler.
Please note though that I'm not advocating pre-mature optimization. However, using profiling tools might give you a better understanding of potential bottlenecks, thus helping you avoid them in the future.