7

According to Brad Wilson, RenderAction is slower than RenderPartial.

However, has anyone got any statistics that show the difference in performance?

I'm in the process of developing an application where pages are composed of "Widgets".

I have two choices:

Composition at the View Level

Call RenderAction for each widget. This is by far the easiest approach but does mean that we're performing a full MVC cycle for each widget.

Composition at the Controller Level

Compose one ViewModel for the page that contains the data we need for each widget. Call RenderPartial for each widget. This is much more complicated to implement but does mean we'll make only one MVC cycle.

I tested the above approaches with 3 different widgets on a page and the difference in render time was 10ths of a second (hardly worth worrying about).

However, has anyone got any test results more concrete than this, or perhaps experience trying both approaches?

Ben Foster
  • 34,340
  • 40
  • 176
  • 285

2 Answers2

5

I've recently worked on an application that was experiencing performance issues, and found a view that was making four calls to RenderAction, plus another one in the layout. I found that each call to RenderAction--even when I added in a dummy action that returned an empty view--took around 200-300ms (on my local machine). Multiply by the number of calls and you have a huge performance hit on the page. In my case there were four calls causing about a second of unecessary server-side overhead. By comparison, calls to RenderPartial were around the area of 0-10ms.

I would avoid using RenderAction wherever possible in favor of RenderPartial. The controller should be responsible for returning all necessary information. In the case of widgets, if you need multiple actions for several widgets, I would try composing them into one action so the RenderAction overhead only occurs once, though if your site performs adequately I'd keep them separate for a cleaner design.

Edit: I gathered this information using MiniProfiler and hitting the site. It isn't super accurate but it does clearly show the differences.

Edit: As Oskar pointed out below, the application in question likely had some intensive code that runs for each request in global.asax. The magnitude of this hit will depend on the application code, but RenderPartial will avoid executing another MVC cycle altogether.

mao47
  • 967
  • 10
  • 25
  • 3
    I doubt that RenderAction() is always 200ms+ - if RenderAction() is always 200ms then a browser request for the same "empty-view" action should also be at least 200ms. But since browser requests in general can be as fast as 10-20ms it seems likely that the application in question has some heavy code (e.g. in global.asax) that runs for each request. – Oskar Berggren Mar 06 '14 at 23:01
  • @Oskar this is true. I haven't worked on that since, but I know it had some pretty serious problems. This is merely to illustrate that the implicit MVC cycle that gets called in `RenderAction()` can have a large performance difference despite appearing so similar to `RenderPartial()`. – mao47 Mar 07 '14 at 12:39
4

I'd suggest 2 more options, both require to compose the view model at Controller level and both can work together (depending on the data)

  1. Html.DisplayFor() - display templates
  2. Helpers via extension methods

Option 2 works very well if you want to keep those widgets in different assemblies, after all they're just functions returning a string. I think it has also the best performance, but of course you lose the 'designer friendly' templates. I think it's important to consider the maintainability aspect, not only raw performance (until you really need it, and even then, caching is more helpful).

For small stuff (date or name formatting etc) i'd use helpers, since the html is usually a span with a class, for more complex stuff I'd use the display templates.

MikeSW
  • 16,140
  • 3
  • 39
  • 53
  • +1 for the DisplayFor() suggestion. I'm currently delegating the rendering responsibility to the widget so I just call `@widget.Render(Html)` and the widget can use the `HtmlHelper` to render itself. That said, I may make this delegation optional and just call `DisplayFor()` by default. – Ben Foster Jun 27 '12 at 22:48