If you are using Visual Studio 2013, download Visual Studio 2013 Update 1 or higher. This update is needed for editing ASP.NET MVC 5.2.1 Razor Views.

What’s in this release?

This release provides a performance improvement in rendering razor pages.

We worked with the MSN team on rendering large pages. When pages render over 80 Kilobytes of data, we end up with objects on the large object heap. When multiple layers of layouts are used this effect can be multiplied.

The result on the server is extra CPU usage, longer retention of memory, and even long pauses during Gen2 cleanup in the garbage collector.

Below is a table demonstrating the results of analyzing a perfview for a run. The CPU is held constant at about 68%, while large pages are being rendered. The table shows that the number of Generation 2 collections has been almost completely eliminated, and the result is higher request rate and a considerable reduction in pauses due to garbage collection.

Area

Before (3.2)

After (3.2.1)

Delta %

Total request (count)

26,986

32,591

20.80%

Trace duration (seconds)

196.20

198.60

1.20%

Request/second

137.53

164.10

19.30%

CPU Load

68.80%

68.50%

-0.40%

GC CPU Samples

124,323

17,543

-85.90%

Total allocations (count)

55,357,146

57,222,949

3.40%

Total GC Pause (samples)

15,091

8,515

-43.60%

Gen0 GC (count)

403

1,216

201.70%

Gen1 GC (count)

290

367

26.60%

Gen2 GC (count)

229

2

-99.10%

CPU / request (samples/req)

19.73

16.47

-16.50%

Update:

How was this done? The Razor page took the data built up in a StringBuilder, and called .ToString() in order to write the string to the wire. Similarly this happened when rendering a Razor page inside a Layout page.

It’s common knowledge that you don’t want to build up a string by concatenating multiple strings. But when the result is large enough, you also don’t want to materialize it into a large string because of the reasons above.

Instead we copy the data into a small buffer, and write to the wire (or the layout page) from this buffer, thus avoiding allocating a large object. Further more the total memory consumed is now reduced because we never have to allocate the full string.

Questions and feedback

You can submit questions related to this release on the ASP.NET forums (MVC, Web API, Web Pages).Please submit any issues you encounter and feature suggestions for future releases on our CodePlex site.

I know that Razor is the preferred view engine, but many (depending on when the app was first put on the drawing board) have inertia that keeps them using the old engine. Any idea how this helps .ASPX or how it compares with using .ASPX ?

@Mike Johnson that inertia can be very difficult to overcome. Ultimately the value gained from converting a ASPX view to Razor is absolutely minimal. If you have a small page that is littered with all the <% %> and other crazy tags. convert it yourself and show people how much simpler it is. After showing how much simpler it is and getting buy in from team members, the next NEW page you are going to build seek to do that in razor.

This allows you to start to kill the ASPX view engine usage by attrition. New development will happen in razor, maintenance on existing ASPX views. Eventually the views will get replaced with new razor views. The best timing of this is when doing a large scale UI or UX enhancement. If you're replacing the backplane of browser to server, say perhaps moving to AngularJS, Meteor or similar, this is a great time to just do all the new work razor.

One of the best ways to win over management support is stress you're not switching to razor to MAKE WORK. You're switching to razor to be MORE PRODUCTIVE. By outlining how you get to continue using all the existing work that there is no "loss" from going back and rewriting ASPX views for the sake of conversion to razor, you'll find most decision makers are open to change when it doesn't reduce EXISTING VALUE.