What's a reasonable amount of memory for a .NE

问题:

I've had a couple of complaints that one of our managed apps is using 20-25Mb of RAM. I normally push back and say that memory's cheap; get over it.

Is this reasonable for a Windows Forms app?

回答1:

20-25MB is nothing.

The .Net framework doesn't always recycle RAM right away anyway. Over time I've seen apps grow to peak at a few hundred MB of RAM during an "expensive" process, and then just sit there even after the "expensive" process finished. However, this is misleading. The app wasn't using this RAM. It's just that the garbage collector hasn't seen a need to collect a lot of old RAM yet. If the operating system had need of that RAM rest assured that it would be collected. The idea that an app should only use a few hundred K at most just doesn't apply in a managed environment — for operating system processes , yes. For native apps, maybe. But not managed code. Otherwise you just end up with systems that have a full GB or more of RAM that just sits idle.

回答2:

That question is like asking "how many apples can you put into a room"...

First I'd counter with asking "how big are the apples"...?

Then I'd counter with "how big is the room"...?

When you've answered those questions it is possible to give a rough estimate. Though realize that even a "Hello World" application on .Net (and Java too for that matter) can take up anything between a couple of KBs to several 100s of Terabytes (theoretically) since the the GCs are mostly constructed so that they allocate greadingly extreme amounts of memory to have in a pool according to how much memory is available. So on a scarce memory computer a .Net WinForms app may take small amounts while on a system with huge amounts of free memory it may take (theoretically) terabytes even for "Hello World"...

回答3:

That's pretty reasonable, yes. Allocating a bit more memory is cheaper than aggressively trying to keep the heap size down by GCing more frequently.

回答4:

There is a potentially valid reason for the pushback: What if your customer is using your app in a terminal services environment, and a dozen or more users are sharing 4GB of RAM? Add your 20 - 25 MB to Outlook's 30+, IE's 20+, Word's 25+ and Excel's 25+, multiply by the number of terminal users, and hopefully you can see where they might be coming from.

I think, in this day and age, 20 - 25 MB is perfectly reasonable. If you're in the hundreds of meg, that might be a different story. But it's all circumstance-specific.

回答5:

What do they actually mean by RAM? Is it Working Set, Private Working Set, Virtual Memory, etc., etc.? I just launched a fairly simple .Net app and it was taking up 21MB of working set, that's 21MB of RAM. But its private working set is only 4MB so about 17MB is being taken up by system and shared libraries that would be used even if my app wasn't loaded.

I then did some fairly memory intensive work with the app and the private working set went up to 28MB. I then switched to another memory intensive app and low and behold my private working set is now 8MB despite the fact that no memory has been released.

An application's use of RAM is extremely difficult to measure and it is even more difficult to decide whether or not any memory use is "too much" (outside of something outrageous of course).

Unless your client is using carefully thought out performance counter measurements to indicate various types of memory use you don't really know how much memory your app is using on their computers.

You don't really have a memory problem what you have is a potentially tricky communications problem depending on the technical know how of the client. But RAM is cheap sounds a little flip and might not be your best approach.

回答6:

It depends what the app is doing. 20 - 25Mb doesn't sound like much to me.

I just created a very simple Windows Form app, with very little on it, and that took 19 - 20Mb. I assume that is probably around the minimum amount of memory a .NET forms application takes.

回答7:

No it's completely outrageous. You call yourself a programmer? My God, man. When I started out, I could fit fifteen applications on a single punch card (that I had to punch with a pair of rusty toenail clippers, btw). They all completed within fifteen CPU cycles and actually CREATED memory out of nothing.

You should be ASHAMED. Resign at once.

回答8:

What are you doing? Does it justify using up about 20 full length novels worth of memory? Is that definitiely your app, and not just the .net runtime overhead? Is the machine in question running low on memory? Does it degrade performance?

That and a thousand and one other questions are what you need to answer :) I personally think that it's a ridiculously huge amount of memory... but then I work on mobile phones where 20mb is about the most I can ever get away with as a maximum heap size :)

回答9:

If your users are using Task Manager to check your app's memory usage, the odds are that they're looking at the Memory Usage column. As Stephen Martin says, this is misleading, as that column actually shows the app's full working set. This is made up of:

• The private working set - resident pages which are private only to your process.
• The shareable working set - resident pages which may be shared with other processes.
• The shared working set - resident pages which are currently being shared with other processes. This is a subset of the shareable working set.

If this is the case, you can play a little trick by manually reducing your app's full working set to its private/shared working set. This is done by using the Win32 API call SetProcessWorkingSetSize(GetCurrentProcess(), -1, -1). This is what Windows will do anyway when the system runs low on memory, but controlling when this happens lets you strip your .NET app's full working set to its private/shared working set. This number is usually much smaller.

How much smaller? Minimising your app to the taskbar does the same thing, so you can check without changing any code.

回答10:

If you have repeatedly caused raised eyebrows with your application's memory footprint, you should at least have a little look at whether you really need this amount or if it is just accumulated inefficiency. Reducing the memory footprint often also brings a speed increase, and that in turn increases customer happiness. Often, this kind of complaint can also hint at other inefficiencies that just look like there is some bloat from the user's point of view.