Mike Taulty's Blog
Bits and Bytes from Microsoft UK
Windows Forms Applications & Memory Usage

Blogs

Mike Taulty's Blog

Elsewhere

Archives

This is probably a daft post but I've been thinking about this post over here http://www.sysinternals.com/blog/2005/04/coming-net-world-im-scared.html which looks at a comparison between  a simple .NET Windows Forms applications and a comparable native application in terms of the amount of processor cycles expended to get the application onto the screen and the number of privates bytes (i.e. pages not sharable with other applications) that each consume.

There's been work done on this in the .NET Framework V2.0 and there are points to be argued about start-up costs of applications, today's incredible hardware and programmer productivity but the comments on the blog post set me to wondering about .NET applications.

How come, when we write two ASP.NET applications we tend to host them in a single process and separate them out by application domain boundaries? How come we don't do this when we write Windows Forms applications for the desktop? What would the benefit be (for code-sharing given that, by default, a number of the core .NET DLLs load themselves in an application-domain-neutral manner) if we worked that way.

So...off I set to do a quick comparison.

Firstly, I wrote the "Hello World" Windows Forms application. A simple Windows Forms form with a label on it saying "Hello World". I ran it debug. Then I ran it release. Then i NGEN'd it and ran it again. The debug version has 14MB of private bytes, the release version has 11MB and the NGEN'd version has about the same.

So, I wrote a second tiny application which simply allowed me to select a .NET executable and launch it in its own application domain. This largely comes down to 2 lines of code I'm using;

AppDomain domain = AppDomain.CreateDomain("Name", null, null);

domain.ExecuteAssembly(d.FileName);

This application has a slightly more advanced UI in that it consists of 2 buttons and a text box. One button raises the OpenFileDialog and allows me to select the executable to "launch" in its own AppDomain whilst the second actually does the launching.

This application has a similar 11MB of private bytes when I run it up.

I then used it to launch the original application in its own AppDomain rather than in a second process. Bringing up the OpenFileDialog took me to 13.5MB of private bytes. Launching my original application (in its own AppDomain) took me up to 16.5MB private bytes. By the time I'd got 5 of these "applications" onto the screen (i.e. 6 AppDomains) the private bytes was at 24MB. So, I'm paying an additional 4.8MB for each copy of this application that I load up in its own AppDomain but that's a lot better than the 11MB that I started off with.

So, alongside all the improvements that are going into Whidbey around performance I was wondering whether there's the possibility of desktop applications having a managed hosting process that's AppDomain based just like ASP.NET applications do so that when I run an application what it actually does is contact a sneaky background app which creates an AppDomain and runs it there instead?


Posted Tue, Apr 19 2005 11:03 AM by mtaulty

Comments

mtaulty wrote re: Windows Forms Applications & Memory Usage
on Tue, Apr 19 2005 3:40 PM
This is a good idea. I dont know much about Longhorn, but I hope they're going to do something like this out of the box.
mtaulty wrote re: Windows Forms Applications & Memory Usage
on Wed, Apr 20 2005 2:46 AM
It's not a daft post at all! I'd be really interested to hear what some of your colleagues have to say about it.

Is stability going to be an issue at all in this sort of scenario? Would it be possible for someone else's application to bring down mine if it crashed and was running in the same AppDomain?

Unless you're talking about an IIS-like application confuration, where you can specify the "application pool" a windows application will run under, so you can get maximum isolation from other processes and greater memory overhead for critical applications.
mtaulty wrote re: Windows Forms Applications & Memory Usage
on Wed, Apr 20 2005 2:48 AM
Sorry - that should have read "crashed and was running in the same *process*"
mtaulty wrote re: Windows Forms Applications & Memory Usage
on Wed, Apr 20 2005 3:25 AM
Just to reply to Mike G.

Yes, there are the possibilities for reliability issues. So, for instance if you really crashed (i.e. access violate or similar) in one of those AppDomains then you can bring the process down although there's been a tonne of work done in V2.0 around this kind of reliability.

There are also security considerations as, from the Windows perspective, a process has an identity associated with it so, be default, all the code picks that up.

But, as you suggest, you could take an IIS6.0 like approach where you set up application pools (i.e. processes) and when you run a managed app you could just pick where you wanted to run it based upon what reliability and identity requirements you had.