EBatista
asked on
C# and Garbage Collection
I have the same problem as many others with C# and Win Forms applications: Huge memory allocated in the manage heap. I have been using Kernel32 function SetProcessWorkingSetSize and it addresses the symptoms by swapping pages out of physical memory but I’m not sure this is the best way to address this problem since one of the supposed goals of managed app is not to worry anymore about memory leaks, reference counting…etc. I know Garbage Collection algorithm, but what I can’t understand (and this is my question): Why GC doesn’t return to the operating system all those MB when the app actually doesn’t need more than few Kb?
I was thinking maybe some Service Pack or VS .NET 2003 has already fixed this problem but I don’t know. Can anybody tell me something about this? I’m using .NET Framework 1.0
Thanks in advance
Elio B.
I was thinking maybe some Service Pack or VS .NET 2003 has already fixed this problem but I don’t know. Can anybody tell me something about this? I’m using .NET Framework 1.0
Thanks in advance
Elio B.
ASKER
Hi farsight, yes but what if the system has only 32MB?. If the app takes about 20-30MB the system will be down soon.
Try it. It wont't allocate as much memory as it will in a system with more memory.
Of course, some minimum is required.
Requirements of the oldest OSes still supported by Microsoft:
Windows 2000 Professional: At least 64 megabytes (MB) of RAM; more memory generally improves responsiveness.
Windows XP Home requirement: 128 megabytes (MB) of RAM or higher recommended (64 MB minimum supported; may limit performance and some features)
Yes, you might run into even lower amounts on old Win98 systems.
My point is that the memory management issue is now delegated to the framework, not to individual programs. It's wise to still do things in a memory-efficient way, and to let the system know when you're done with objects, but beyond that, it's just not something to be concerned with. You can only make performance worse by mucking around with it. Move on to problems you have some control over. If a program doesn't work on a system due to memory contraints, just upgrade it. It'll be cheaper than your time, anyway.
(If you're still using direct Win32 API calls that allocate memory, you'll need to free that up, too, of course.)
Do you ACTUALLY have a memory problem, or is this all theoretical?
Of course, some minimum is required.
Requirements of the oldest OSes still supported by Microsoft:
Windows 2000 Professional: At least 64 megabytes (MB) of RAM; more memory generally improves responsiveness.
Windows XP Home requirement: 128 megabytes (MB) of RAM or higher recommended (64 MB minimum supported; may limit performance and some features)
Yes, you might run into even lower amounts on old Win98 systems.
My point is that the memory management issue is now delegated to the framework, not to individual programs. It's wise to still do things in a memory-efficient way, and to let the system know when you're done with objects, but beyond that, it's just not something to be concerned with. You can only make performance worse by mucking around with it. Move on to problems you have some control over. If a program doesn't work on a system due to memory contraints, just upgrade it. It'll be cheaper than your time, anyway.
(If you're still using direct Win32 API calls that allocate memory, you'll need to free that up, too, of course.)
Do you ACTUALLY have a memory problem, or is this all theoretical?
ASKER
It's Itheoretical, I'm programming a large system in my large enterprice, my OS is XP Pro 256MB, but some clients still have W98 32MB. In my PC the App runs fine but I was concerned about this clients. Do you know any documentation about what you are teelling me? I already red the GC documentation at MSDN site, but it don't tell nothing about this.
Unfortunately, I don't have a link. I read somewhere (perhaps here on Experts-Exchange) about a guy who was worried about the same thing. He started lots of instances of his program, and when the machine started getting low on memory, the new instances would take a far smaller chunks.
It sounds like you could do some direct experimentation yourself by commandeering a 32MB Win98 machine. Try it out and see if there's a problem. (If you do, let us know.) But even if there is a problem, there is little you can do about it. The memory management and GC are well-tuned.
When you say "some" clients, do you know how many? With PC-100 memory at $22 for 64M, even a hundred machines could be upgraded for less than you make in a month (assuming a good US salary).
It sounds like you could do some direct experimentation yourself by commandeering a 32MB Win98 machine. Try it out and see if there's a problem. (If you do, let us know.) But even if there is a problem, there is little you can do about it. The memory management and GC are well-tuned.
When you say "some" clients, do you know how many? With PC-100 memory at $22 for 64M, even a hundred machines could be upgraded for less than you make in a month (assuming a good US salary).
By the way, this is definately a .NET issue, not just C#, because VB.NET behaves the same way.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the links, now look at what I have done ,I have made two test in my own PC (XP Pro 256MB), this is what I did:
I started my App, it allocated 19 MB, and then I opened 53 instances of Internet Explorer, each instance allocated 5-12 MB, when launching the 41 instance of IE, the memory allocated to my App started to go down, and then it came smaller and smaller with each new IE's instance, when I reached the 53, the memory for my app was only 800Kb!!!. This was very good news to me because I was a little disillusioned with the GC and the managed heap at the point that I was thinking to go back to C++, but now I'll go on with C#.
Thanks again farsight
EBatista
I started my App, it allocated 19 MB, and then I opened 53 instances of Internet Explorer, each instance allocated 5-12 MB, when launching the 41 instance of IE, the memory allocated to my App started to go down, and then it came smaller and smaller with each new IE's instance, when I reached the 53, the memory for my app was only 800Kb!!!. This was very good news to me because I was a little disillusioned with the GC and the managed heap at the point that I was thinking to go back to C++, but now I'll go on with C#.
Thanks again farsight
EBatista
It *IS* strange isn't it?
Thanks.
Thanks.
Just stop worrying about memory management. It's not your problem any more.
Let the .NET Framework handle it.
It will only allocate a lot of memory if a lot of memory is available.