tags:

views:

91

answers:

4

Hi

I am just wondering how much of a performance will you lose by using lots of partial views and html helpers in an asp.net mvc application.

Like I know html helpers are to be light weight but I can't see them rendering as fast as if you just made straight html.

Don't get me wrong I love them but just curious on how much they would impact your site. I am guessing not much but some of these html helpers can get complicated and do quite a bit.

Also I like using partial views since many of my parts of my site need basically the same code so might as well try to eliminate the duplicate code so I like putting it in partial views.

How much of a performance impact do partial views have?

+2  A: 

I have no evidence to back this up, but I'd assume almost none. Especially for HTML Helpers - its just an extra method call. You could copy and paste the code from the helper into the View and you'd only have accomplished having one less method on the stack.

JoshJordan
+1  A: 

Your server hardware and network infrastruture will be more of a limiting factor than the html helpers and partial views. Don't think about it.

Jaimal Chohan
A: 

This is premature optimisation. Write it first, then profile it, and if you find that performance doesn't meet your requirements/SLA, use the profiling tools to find the poorly performing code. It probably won't be the html helper methods, it'll be things like database calls and other cross process calls.

Neil Barnwell
Any good profile tools? I am a long way off from needing one but this was just more curiosity to see how much they would use. I doubt a problem come frome them though.
chobo2
ANTS Profiler by Redgate is the only one I've used. It works pretty well.
Neil Barnwell
+1  A: 

I generally agree that there is almost no overhead, and that it would be premature optimization to avoid either. However, there are two important exceptions you should be aware of:

  • Using lots of partial views will be very slow when the ASP.NET compiler compiles in debug mode only. In debug mode, MVC doesn't cache file locations, so it must probe every time it renders a view. Don't be fooled! This issue goes away in release mode.

  • In the MVC Futures assembly for MVC 1.0, there are some "strongly typed" HTML helpers which are (1) about 10x slower than the helpers in the System.Web.Mvc assembly and are (2) probably incompatible (in terms of syntax) with the (presumably improved, from a performance POV) "strongly typed" helpers coming in MVC 2. I'd suggest staying away from these.

But in general I agree: Write correct code first, then profile.

Craig Stuntz