What is a reasonable amount of memory for a .NET application?

I had several complaints that one of our managed applications uses 20-25 MB of RAM. I usually backtrack and say that memory is cheap; get over it.

Is this reasonable for a Windows Forms application?

+2
source share
10 answers

20-25MB is nothing.

..Net framework does not always recycle RAM anyway. Over time, I saw applications grow to several hundred MB of RAM during an “expensive” process, and then just sat there even after the “expensive” process was completed. However, this is misleading. The application did not use this RAM. It's just that the garbage collector has not yet seen the need to collect a lot of old memory. If the operating system needed this RAM, make sure that it will be built. The idea that an application should use only a few hundred K is, in most cases, not applicable in a managed environment - for operating system processes, yes. Perhaps for native applications. But not managed code. Otherwise, you just get systems with full GB or more of RAM that just sit around.

+7
source

This question is similar to the question "how many boxes can be put in a room" ...

First, I would meet the question: "How big are apples" ...?

Then I would meet "how big is the number" ...?

When you answered these questions, you can give a rough estimate. Although, understand that even a Hello World application on .Net (and Java, too, for that matter) can occupy anything between a few KB and up to several 100 terabytes (theoretically), since GCs are basically designed so that they emit robbery in volume sufficient to have available memory. Thus, on a limited computer with memory, the .Net WinForms application can accept small amounts, and on a system with a huge amount of free memory, (theoretically) terabytes may be required even for "Hello World" ...

+4
source

This is pretty reasonable, yes. Allocating a bit more memory is cheaper than aggressive, trying to reduce heap size due to GCing more often.

+4
source

There is a potentially valid reason for pushback: what if your client uses your application in a Terminal Services environment and dozens or more users use 4 GB of RAM? Add your 20-25 MB to Outlook 30+, IE 20+, Word 25+ and Excel 25+, multiply the number of terminal users and hopefully you will see where they can come from.

I think that day and at the age of 20 - 25 MB is quite reasonable. If you are in hundreds of meganes, this could be a different story. But all this is a circumstance.

+3
source

What do they really mean by RAM? This is a working set, a private working set, virtual memory, etc. Etc.? I just ran a pretty simple .Net application and took 21 MB of working set, this is 21 MB of RAM. But its private working set is only 4 MB, so about 17 MB are involved in system and shared libraries that will be used even if my application has not been downloaded.

Then I did a rather intensive job of memory with the application, and the private working set increased to 28 MB. Then I switched to another memory intensive application, and I saw that my personal working set was now 8 MB, even though the memory had not been released.

Using application RAM is extremely difficult to measure, and it’s even more difficult to decide if memory usage is too “redundant” (beyond something outrageous, of course).

Unless your client uses carefully designed performance counter measurements to indicate the use of different types of memory, you really don't know how much memory your application uses on their computers.

You really do not have the memory problem that you have, it is a potentially difficult communication problem depending on the technical know-how of the client. But RAM sounds a little flip cheap and may not be the best approach.

+3
source

It depends on what the application does. 20 - 25Mb for me is not very like.

I just created a very simple Windows Form application, it is very small with it, and it took 19 - 20Mb. I guess this is probably due to the minimum amount of memory that the .NET forms application accepts.

+2
source

No, this is absolutely outrageous. Do you call yourself a programmer? Oh my god, man. When I started, I could put fifteen applications on one punch card (I had to break through a couple of rusty nail cliches, by the way). All of them completed within fifteen cycles of the processor and actually CREATED memory from nothing.

You must be BACK. Go down right away.

+2
source

What do you do? Does this justify the use of about 20 full-fledged novels? Is this definitely your application, not just the .net runtime overhead? Is the machine in question low in memory? Does it degrade performance?

That and a thousand other questions - that’s what you need to answer :) I personally think that this is a ridiculously huge amount of memory ... but then I work on mobile phones, where 20mb is the most I can ever get with the maximum heap size :)

+1
source

If your users use the task manager to check the memory usage of the application, chances are that they are looking at the Memory usage column. As Stephen Martin says, this is misleading as this column actually shows the full working set of the application. It consists of:

  • Private desktop - resident pages that are private only for your process.
  • A shared work resource is resident pages that can be shared by other processes.
  • General desktop - resident pages that are currently shared by other processes. This is a subset of the shared working set.

If so, you can do a little work by reducing the working set of applications to its personal / general working set. This is done by calling the Win32 API SetProcessWorkingSetSize (GetCurrentProcess (), -1, -1) . This is what Windows will do anyway when the system is running low on memory, but controlling when that happens will allow you to fully install the working set of .NET applications on your private / shared working set. This number is usually much smaller.

How much less? Minimizing your application on the taskbar does the same, so you can check without changing the code.

+1
source

If you have repeatedly raised raised eyebrows with the occupied memory of your application, you should at least look a little if you really need this amount or if it simply accumulates inefficiently. Reducing the amount of memory often also leads to an increase in speed, which, in turn, increases the happiness of customers. Often, such a complaint may also hint at other inefficiencies that simply look as if there is some bloating from the user's point of view.

0
source

Source: https://habr.com/ru/post/891942/


All Articles