April 21, 2005
Mark Russinovich recently posted a blog entry bemoaning the bloated footprint of managed .NET apps compared to their unmanaged equivalents. He starts by comparing a trivial managed implemention of Notepad to the one that ships with Windows:
First notice the total CPU time consumed by each process. Remember, all I've done is launch the programs Ã¢â‚¬â€œ I haven't interacted with either one of them. The managed Notepad has taken twice the CPU time as the native one to start. Granted, a tenth of a second isn't large in absolute terms, but it represents 200 million cycles on the 2 GHz processor that they are running on. Next notice the memory consumption, which is really where the managed code problem is apparent. The managed Notepad has consumed close to 8 MB of private virtual memory (memory that can't be shared with other processes) whereas the native version has used less than 1 MB. That's a 10x difference! And the peak working set, which is the maximum amount of physical memory Windows has assigned a process, is almost 9 MB for the managed version and 3 MB for the unmanaged version, close to a 3x difference.
While Mark has more coding skill in his pinky finger than I have in my entire body, I think his comparison is misleading at best and specious at worst. He clarifies his position in a subsequent post:
Memory footprint is much more important for a client-side-only application since there can be many such applications running concurrently and clients often have limited memory. Someone stated that by the time that Longhorn ships most new systems will have 1 to 2 GB of memory. In corporate environments clients have at least 3-year life cycles and home users even in prosperous nations might upgrade less often. In developing nations you'll see system configurations lagging the mainstream by 5 years. That means that most of the world's computers won't have 1-2 GB of memory until several years after Longhorn finally ships.
It's amazing to me that no matter how much memory we add, how much faster we make our CPUs, and how much faster we make our disks spin and seek, computing doesn't seem to get faster. If you have a Windows NT 4 system around compare its boot time and common tasks with that of a Windows XP system. Then compare their system specs. Then ask yourself what you really can do on the Windows XP system that you can't do on the Windows NT 4 system.
I'm not sure why this trend is currently bothering Mark so much, because it's been going on for decades. The subset of tasks that must be done in (insert favorite low-level language here) for acceptable performance gets smaller and smaller every day as hardware improves over time. This is a perfectly reasonable tradeoff to make; computers get faster every day, but our brains don't. The goal of the .NET runtime is not to squeeze every drop of performance out of the platform-- it's to make software development easier. A talented developer could write several managed .NET apps in the same time it would take to write one unmanaged C++ app. Would you rather have a single fast native app, or a dozen slower managed apps to choose from?
Mark's article did get me thinking about the inherent overhead of .NET. What is the real minimum footprint of a .NET application?
First, I started a new Console C# project in VS.NET, then added a single Console.WriteLine and a Console.ReadLine. I compiled in release mode, closed the IDE, and double-clicked on the release executable. I then used Mark's Process Exporer to view the process properties:
|.NET 1.1||.NET 2.0 b2||.NET 2.0 final
|Private Bytes||3,912 K||6,984 K||7,076 K
|Working Set||5,800 K||3,792 K||3,872 K
Next, I started a new Windows Forms C# project in VS.NET, then added a single close Button and a label. I compiled in release mode, closed the IDE, and double-clicked on the release executable. I again used process explorer to view the process properties:
|.NET 1.1||.NET 2.0 b2||.NET 2.0 final
|Private Bytes||5,760 K||11,432 K||11,684 K
|Working Set||7,876 K||7,280 K||7,072 K
(Updated with .NET 2.0 final numbers on 1-12-06. I generated these numbers in a clean Windows XP VM, so they should be accurate.)
The .NET 2.0 beta results were generated on a different machine via Remote Desktop, but I don't think that should affect memory and handles. Maybe it's my VB background talking, but these baseline footprints seem totally reasonable to me, particularly considering the incredible productivity I get in exchange.
Posted by Jeff Atwood
That's pretty much a given..
Minimizing a window always causes the working set to be cleared (Windows Explorer calls the OS function SetProcessWorkingSetSize(h,-1,-1) when it minimizes the main appliation's window).
Those baselines seem OK to me too [for an application with a button and a label].
I agree completely about the productivity gains, but let's not ignore the elephant in the room. Developers of commercial software may not be able to justify the resource needs vs. productivity gains.
I didn't think you're supposed to release performance metrics of pre-release products? In any case, expect memory usage to go down.
I would expect a significant drop in disk and memory footprint in the final product(s), of both the framework and VS2005.
The current builds are not optimized, and probably have a significant amount of debugging information...
I'm worried about some of the same things as Mark is. About 5 years ago, I worked on a distributed near real time system for our company's trading arm. We ended up with 1 process/desk, and 3-4 processes for each of the intermediate steps in processing the data, and a couple of large data caches. This was running on 2 servers with 4 processors each, and 2 GB of RAM each. We ended up with over 100 processes/server, at ~1.7 GB memory utilization per server.
Most of our applications were in Delphi and C++, with a couple of Java processes (which had to be tuned for memory performance). I'm pretty sure that if we had used managed code, the additional memory footprint of just the code would've pushed us over the 2 GB mark. Our choices would've been to stick everything in the GAC or write monolithic applications that made heavy use of threading. Niether one is particularly appealing.
Also you're comparing building an app in C# vs. C++. I think that you're really comparing it with MFC, which is notoriously difficult to use. I don't find C# to be any easier to use than Borland's Delphi and only a little better than C++ Builder. There's also Sybase's ill starred Optima++, which also made GUI programming easy.
Marty, I noticed the same things:
1) minimizing the form reduces the WinForms hello world app working memory set drastically.
2) the footprint of any additional code, after you've "paid" for the baseline .NET runtime costs, is relatively small.
In the end, you have to compare real apps to real apps; there are too many variables for the "managed sample notepad app to unmanaged notepad" to be a valid comparison. Not to mention that unmanaged notepad kinda sucks at any size and speed.
Well in an Ideal world youd be able to compile to Native Win32, .NET, Linux and even Win16(at a pinch) all from the same source code......
So you could support paranoid fat corporate Workstations, cheap people like me still running on pentium II, and the oddballs on unix. :)
You guys ever heard of Delphi...??
Code once compiles to all the above platforms one codebase one IDE......
Still probably better to stick with Microsoft after all, werent they ones that looked after your compatibility so well when we went from 16bit to 32bit (I feel old)... and they've done a super job with VB6 to VB7...
Delphi is written in Delphi therefore if they break your code they break theirs too...kinda gives me a warm feeling that.
"The goal of the .NET runtime is not to squeeze every drop of performance out of the platform-- it's to make software development easier. "
Umm, what part beacme easier? I think "Managed" is just an acronym for "Mainly A New Avoidance of Good Engineering Design".
asp.net compared to asp is interesting. asp.net requires the vs environment rather than a simple text editor, it creates immense code, most of which is only required by the aforementioned vs environment. If you have to make a simple textual change, you have to recompile the application rather than just make the change and keep going. Asp.net apps start slower and are css inflexible. The list just goes on and on.
Well said Jeff. There seems to be people in this world who think that they are 'hard-kore coderz' cuz they squeeze an extra K of memory on the stack cuz 'managed-code sucks, man'. I wonder who pays these hackers the extra time it takes for them to do that? Do people realise it costs less than $0.01 to buy that 1Kb of memory? Do they realise the memory is also likely to have fewer defects than geek-boys code?
Well well, managed code is for kids who don't know how to write programs. For professional level it simply sucks. I wonder why people come to programming or call them programmers if they can't write high performance programs. A skilled unmanaged programmer finishes entire project well before a skilled managed programmer could finish the same project (provided the project is big enough so that coding will continue for several months). It takes time only for kids who don't know how to write programs.
I am tending to not agree at the moment that the baseline memory footprint of .NET is acceptable. I have been working on a Windows Forms application for a client, and the memory bloat has the client believing the application is leaking memory. I can't really prove that the app isn't leaking memory, so I am going to end up on a wild-goose-chase to see if I can reduce memory consumption because of the bloat. I am sure I will find a leak or two. I never thought I would have to call Dispose so much when I started .NET development. Where is the Garbage Collected paradise?
Oh, and fix the comment form so I can put my Google blog address in the URL box. The domain is getting flagged as questionable content!!!
I am seeing a great deal of misconceptions in regards to the way the CLR allocates memory.
What you are calling memory bloat is actually by design and for very good reason.
.NET allocates as much memory as the application may need for inital compliation (don't forget that your nifty code is JIT complied from IL into machine code at runtime) and for running.
The CLR allocates this memory upfront as it is faster to allocate a large block upfront than it is to keep allocating small blocks of memory (hence the 7mb base footprint of all .NET applications). This is common practice for high performance applications and many game engines do the exact same thing.
If you near the memory limit then when the CLR allocates memory it allocates roughly twice as much memory as actually needed in case you need to allocate more memory in the near future thus avoiding the performance impact of that allocation and the readjustment of the GC in order to cope with that allocation.
Should the system become low on memory the CLR automatically frees any unused memory for use by the operating system. You can test this by starting the "one button" sample form as discussed above and then loading the up the system with other applications while keeping the form maximised. You will notice that the footprint of your CLR application gets reduced at this point.
This guys as it happens IS in the rotor/GC docs should you wish to read them.
The whole concept that managed code gets the job done quicker or in my opinion the use of one programming language over another is misleading at best. Those working a particular space would be best served by investing their time in a good initial design that conciders the entire product lifecycle for what they are building and finding the necessary common supporting libraries to get the job done effectivly.
The idea that you don't need to worry about managing resources is fine on some level but it quickly breaks down in any serious application. If you don't know what I'm talking about its because you havn't worked on one. Memory is cheap however connections, synchronization objects, threads, transactions, and various OS handles are not. You simply cannot elect not to manage resources and expect a serious application to continue to operate in a sane and reliable manner.
When it comes down to it *yes* you still have to manage resources on some level regardless of what modern marvel of a programming system you are using and *no* if handled properly this does not have an appreciable effect on the time it takes to get a particular job done.
I've written entire perl applications that use nothing but automatic variables (None explicitly defined or referenced) in a few minutes that would have taken hours to do in any other language that I'm aware of. Thats well and good but we all know full well that serious medium to large scale applications can't be written this way.
I happen to be in Mark's camp. I think .NEt is a step in wrong direction. Microsoft technologies have always been difficult, and in-efficient, and .NET is probably the worst.
By constatnly saying that you need 2GB memory to run the latest and the greatest, you almost make them foget to ask why? Why does the new application has to be 10 times bigger, AND 10 times slower, thereby offsetting the advantage of the improved hardware? Just so that you can have 10 such applications? How many applications do you really need (per task of-course)? One good one or 10 sluggish ones?
Secondly, as far as rapid application development is concerned, even there .NET is a failure. It's languages are poorly designed, and hence will keep on changing. Somehow we have come to equate that newer versions of languages (CLR 1.0, CLR 2.0, DXD1 - 10) is an acceptable criteria to judge the 'maturity' of a product. Well, these are not products. These should be thought out properly to begin with, so that they stay stable and people can use them to develop products. Products, developed by using the tools are what should have versions, with features added and improvements included.
And finally, (sorry this is getting long), the oft-touted rhetoric that you can develop in ANY language is nonsense. But all these languages are really not different. Their is only one underlying language, CLR - and all the .NET languages are really just syntax sugar coating around CLR. They can not offer anything above and beyond what is there in CLR. A far better alternative is to differentiate the languages based on their 'class'. Machine level (assembly), main programming (C/C++, Fortran), and then scripting (Perl, Python, Ruby), etc. .NEt languages are much more difficult compared to the above mentioned scripting languages, and much less powerful too. And they are too slow for main-programming category as well. A newer alternative to programming is to use a scripting language to design the shell and logic of your application and implement main engine in a main programming language. I know about Python, that it lets you do that and I belive Python (Lua, or Ruby too), + components developed in C/C++ are the way to program CORRECTLY.
Obviously spoken by someone that never developed anything in .NET.
The share fact you say things like it needs 2G to run and that it's ten times slower tells me you don't know the first thing about .NET, try looking up "ngen" in the documentation.
Yes. I think alot of people on here bagging .NET haven't actually looked further into the platform than Oh this is visual studio, oh i'm going to create something with this without any idea of whats really happening, then i'm going to 'bag it' based on memmory footprint (without actually having any idea on how its managed and why). Seriously people, where I work (investment bank) our transaction management app relies heavily on c code....to this day (15 years in the go) its still having holes plugged..memmory leaks...give me a break guys. We're rolling out .NET and its simple why, time to market is more important and worth so much more than hardware...people the main arguement here about hardware requirements...are you people serious??? Anyone running a decent .NET app is likely going to have a spec'd up machine anyhow..and how CHEEEAP is memory, so lets please drop that. Java doesn't get the drilling .NET does even though hands down .net mem management is superior.
Geeks are losing their footholding, and not liking it..so naturally they will bag something like .NET. But for now. .NET really is superior in business applications, its time to market, amazing Visual studio (even the freee edition is an awesome tool).
But it is rather scary all the people calling themselves programmers whlie using the GUI magic to create their apps in vis studio...having all their data/business logic in the form classes..haha but common guys unless we're doing low level stuff, game engines...etc etc if not those then we're programming for the business world..and NOTHING beats time to market (obviously with reqjuirements being met etc etc). .NET gets that shit sorted.
now we have a free IDE, we get IIS on almost all windows, hell someone tell me ms sql express isn't a pretty good deal. Plus you can't ignore the amazing support MS gives to its platform.
in the end, geeks want to be elite - be those special guys who can write code how it orginally was 'hardcore'. But thats fading in the real world, IT is a tool for automating proccesses (spelling?) and .NET gets it done in a fraction of the time.
still not to worry, all you guys loving the old school way can still do your hobby at home, or get jobs for game developers, security agencies. but remember code is just a tool, and like all tools the more automated, the easier to use the better. We must not fall in love with coding and fight the natural adaptation which all tools must go through. Its the process which the code is solving which is the important thing to focus on!
oh and just because a tool adapts....becomes more usable..doesn't mean your safe...still goto look out for those 'guys' who are first time programmers growing up in .NET ....no comp sci degree, or real self training.......but hey. its the process we're solving people. And lets not get into a speal about performance....i'm assuming we're not talking about COMPLETE idiot programmres....who are never safe to be around on any platform.
as a final word. Please try and use .NET to create a real application. Get a real feel for it, read a few tech books (not god damn internet posts), get a feel for the IL.....then judge it.
oh and if your going to go down the asp.net path...you'l appreciate C# for your web coding language...just STAY CLEAR of the html controls that ship with asp.net :)
oh bugger to top this all off!. guys, we're all using windows (now you know what i mean by ALL)...and .NET leverages our operating systems like you wouldn't believe..if you really get dirty with .NET you'l see with the OS at its whim...its an elite tool with a broad spectrum.
Who cares about geeks? Geeks just bite the heads off chickens. Nerds are generally more effective as computer programmers. Geeks bite chicken heads, jump around, and shout to the world how .Net let's them write in a language that looks a lot like C - curly braces! Wow! (chomp, munch).
Dot Not is anything but a productivity tool if you already know the APIs. Who wants to write in a language that keeps changing, getting more scattered, and not living up to its "write once, deploy everywhere" promise? Even KR or Ansi C have a lot more platforms and great applications under their belts.
And don't slam Delphi if you write Win32 apps. It was a productivity dream, with handy design and tools plus a compiler that runs circles around the VS Dot Not implementation. Where the Dot Not developer is searching for a "workaround" to the latest bummer, the Delphi or C programmer is long done. Dot Not is an illusion, and an expensive waste of computer resources.
So you say "hey, it saved me ten minutes." But if thousands or millions of people use that crummy code that saved you ten minutes, yet it cost each user thousands in hardware, time, downtime; not to mention the waste in the landfill for all the old computers, what savings is that?
Dot Not writers don't seem willing to admit how often they break down and purchase add-ons written in, guess what? C!; or how often they have to keep buying new versions of those ever more expensive add-ons that do some pretty simple things.
Dot Not for Linux? Where? For Sun? For Mac? Nope. It's just Dot Not. And who wants to have their program code look like code from a classic language only to have it degenerate into the same muck as anything else? At least with C, one can get it close to assembly if desired, or in most cases, even include inline asm code.
With Dot Not, the project takes longer and longer toward the end. By doing it the "hard way" from the start, avoiding Dot Not, the project actually gets easier near the end.
One thing about Dot Not that is positive for application programmers is that it keeps them in a job. With all the new versions, bug fixes and patches, there's always something to do. Another great part about Dot Not is that it creates jobs for competent programmers who will write replacements for those Dot Not programs.
Face it - Dot Not coders know their own dirty secret, but the "Platform" let's them be silly and brag about what "Geeks" do with curly braces. Dot Not IS for Geeks.
Real nerds, and real programmers just say Not. Dot Not.
I've programmed in more than a dozen languages and I have never seen any lack of productivity on any of those languages.
C# has not proven to be a productivity enhancement for me at all, in almost 5 years of programming with it. Yes, you can produce applications more quickly if they do nothing but standard stuff, but if you try to do anything interesting at all, you're stuck writing adapters from unmanaged code to managed code, and they suck; not to mention all the obscure bugs that pop up that you have to write workarounds for, like formatted text boxes that do not work correctly with selectall, a flaky datagridview and a plethora of other problems in the .Net API. It gets so bad sometimes that I'd rather just have a pointer to the display, and the propensity of people to rely on the .Net library alone is churning out loads of low-quality programmers.
Other programmers are willing to argue with me that the bloat is worth it, but they never consider the guy who is running a P-133 just to clock in and out of his machine using your app, but he can't run your app because it runs him out of memory. There is no reason to give him anything bigger, and there are plenty of reasons to write smaller code. All he cares about is the app he used to run works and the current one doesnt.
They also don't consider the people who run loads of applications at once. Aggregately the cost of bloat gets even more expensive. I would not be so dismissive of bloat; your entire argument for bloat is that it's acceptable because that's the way the industry is headed.
That's no argument at all.
Customers only care that it's fast and it works. They don't care what language you coded it in, and if you rewrite an application in .Net and don't introduce any new features, all they're going to ask is why it is so much slower than it was before.
Something to consider also is that the footprint of a managed application seems to have a base amount, and then increasing the complexity of that application doesn't necessarily increase the footprint by much.
For instance, just to test this, a while back I created a blank windows form and looked at the memory usage in the task manager. I then loaded up a fairly complicated form application that my company was using, and it only consumed 2k more memory than the blank form.
One oddity I ran into while testing memory issues with form applications was that when a form is minimized and then restored, the footprint got significantly smaller. The example I had was a basic form with a few controls that started off at 14k usage, and after the minimize/restore it had 4.5k. I added in a call to minimize/restore the window upon loading and I saw the same benefit in the decrease of memory usage.
This is all according to Window's task manager, and I have no idea how accurate a tool that is to gauge an application's footprint.
To sls: There were a lot of (common) misconceptions in your rant.
You can code ASP.NET just fine with any text editor.
Yes, VS creates lots of unnecessary code for you, but that's VS - if you don't like it, you can always delete the extra code or use Visual Notepad.
If you want, you can create a .NET web app that consists of a single ASPX file, with no code behind, i.e. with C# (or whatever your language flavor) mixed in with the HTML, just like with traditional ASP. Not that I'm advocating this development model.
The start up time you mention for ASP.NET is comparing apples to oranges. Pages served through the ASP.NET runtime are precompiled (thus the start up time), whereas traditional ASP pages are interpreted. That means the first time an ASPX page is accessed, it will be slower, yes. But after that first page access, the ASPX is orders of magnitude faster than ASP.
In fact it's possible to program ASP.NET in almost exactly the same way as it was done in ASP and the result would almost certainly be more performant. Again, I'm not suggesting that you should do this, only that it's possible.