Brian Hartsock's Blog

I have been playing with WPF over the past few weeks, and I kind of like it. What’s odd is I hate Web Forms, which has very similar concepts to WPF. Concepts like controls, data binding, data templates, etc…

Why do I think WPF works while Web Forms don’t?

The first step is really understanding what I dislike in Web Forms. Two reasons, ViewState and controls.

ViewState

I hate the ViewState. It is a very complex mechanism of changing a stateless medium, HTTP, into a stateful one. While it accomplishes that task, I don’t believe the trade-offs are worth it. Developers must understand how HTTP works, and how the ViewState works. It is not an abstraction that allows ignorance because it leaks all the intricacies of HTTP as well as adding a ton of complexity on top of it.

I think understanding HTTP is stateless and coding your application to work in that medium is much easier than coding your application to be stateful and fixing it to work in a stateless medium.

Controls

Imagine you had a markup language that controls how something is displayed. It is ubiquitous and highly standardized. Now create an abstraction that wraps it, hides the simplicity, and adds ViewState, which I obviously don’t like. That is what controls in Web Forms are.

Let me interject that I don’t hate controls like I hate the ViewState. I actually like some of the principles behind them. The ability to easily reuse HTML is great. The ability to data-bind to objects is awesome.

What I don’t like is the fact that I believe it is an unnecessary abstraction. At the end of the day, all a browser cares about is HTML. And I love HTML and am good at HTML. Why take that away from me? Not to mention things like repeaters are just foreach loops.

Why is WPF different?

Two reasons that you can probably guess.

Desktop apps are stateful. There is no ViewState. There is just memory. And I understand memory.

Controls are the real thing, not an abstraction around the real thing (Yes I understand they are actually an abstraction around something, but it is a good abstraction. One that doesn’t leak like crazy. I can ignore how it works under the hood).

Now WPF isn’t perfect. Unit testing out of the bag isn’t easy, but it is possible. Just like using model-view-presenter is possible in web forms.

I was reading through some posts on ASP.NET best practices, and a lot is mentioned about <compilation debug=”false” /> on production machines. One thing that seems to be glossed over is <trace enabled=”false” />. Obviously, tracing is a security concern, but does it hurt your application in other ways?

The biggest area I thought tracing could effect an application was memory, so I wanted to see the memory differences of having trace enabled, vs having it disabled.

Test #1 – Trace enabled

<trace requestLimit="5000" enabled="true" mostRecent="false"/>

I loaded up an instance of one of our ASP.NET applications on my machine, and ran a script that generated random hits on a few of the pages.

After about ~4500 requests, here is what perfmon read.

Test #2 – No Tracing

<trace requestLimit="5000" enabled="false" mostRecent="false"/>

Ran the script again, and saw some pretty interesting results.

The Word

At first, the results look the same, but look closer. With tracing enabled the # of Bytes in all Heaps is 710MB, vs 72MB without tracing. That’s a 10x difference! The Gen 2 heap is where most of the difference lies, which is a whopping 692MB vs 65MB. This heap should only contain very long lived objects. Having a growing Gen 2 heap is also going to indicate the need for IIS to recycle soon, since memory obviously isn’t getting deallocated.

If you are running with <deployment retail=”true”/>, then you don’t have to worry about this on production machines. Still, it is important to know the effects that tracing can have on you live environment.

If this graph isn’t making a lot of sense, check out this article on debugging memory problems.