VB.Net and erractic memory handling??

I have found that VB.net 's memory handling is very erratic at best.

Problem:
I built a small app in VB6 that pings a server periodically for information. The app uses approx 4500kb in memory. I built a similar app in .Net and it uses 14000kb! and as the program is working it gets larger...and larger.

Strange I thought, I must be allowing objects to live without disposing of the properly, I then went through all my code killing everything that wasnt nailed down. Still the same.

After a couple of days trying to get the program to conform, I noticed that if I minimised the main window to the task bar then set its state to normal again the memory usage would promply go down to 3000kb. As the program was working the memory usage would rise again, so I would perform the minimize...maximize (normal) trick again and yes...it went back to 3000k again.

At this point I tried playing around with the Garbage collector, fearing that it wasnt working properly, but that had no effect.

So in a nutshell I have a program that starts off using 14000kb (9500kb more than its VB6 equivilent) of memory until I minimize then maximize (normal) its main form, then the memory usage goes down by 11000kb!

The program runs for long periods (weeks/months) and the only way to stop it using vast amounts of memory is to periodically make the app automatically minimize then maximize!!

Now to me this seems rather odd! has anyone else noticed this?

Is this a bug?

Does anyone know a fix??

Thanks
Imogen

PS I have built the final exe's in release mode etc....

Sound awful acctually, not only the behaviour with the minimize thing but also the 9.5Mb more usage than VB6!!

When you messed around with the garbage collector did you then also programically force a garbage collection?

Quote:

---

When you messed around with the garbage collector did you then also programically force a garbage collection?

---

Yes I did, this had no effect. The only thing that has an effect is the minimizing of the form.. as previously stated

Regards
Imi

There is nothing to worry about.

I don't quite recall where i read this from but the memory management and garbage collection works.

At the start of a program it anticipates how much memory might be used and also how much ram there is in total in the system and probably the fragmentation level of the memory in the system.

It uses these parameters to judge how much memory to take up. It doesn't actually uses it but just reserve it for use by your program so that when your program eventually grows to that size after opening some controls, forms, objects, etc, it won't have to look around for memory here and there from every nook and cranny.

So from what you're saying, i'll guess that the clr is clever enuff to know that if you're minimizing the program, it's priority is lower and therefore it won't be using that much ram, so less ram is allocated to it and freed up for other programs.

So the clr is not being erratic, it's just being intelligent (or it tries to be). And i believe using this method, the clr also reduces memory fragmentation by your program because it allocates one huge block at the beginning and fragmentation only begins only when that reserved amount is insufficient.

Yes, don't worry about the ram usage. Do you worry that Windows when started up takes 80% of your RAM? No, because Windows will give it up if it needs to.

Same with .Net. It is trying to be smart and reserve itself some memory. If something else needs memory, it will be released. From everything I have read and heard, the .Net GC is one of the best things about the Framework. It is definately more advanced than the Java GC, and that has been around for a long time. As a matter of fact, the guy that created Java, created C#, but included all the extra stuff he forgot to add to Java...lol.

Just enjoy your programming and don't worry about it.

I still think 4 times the memory usage is alot for being smart. I guess you cant help the feeling that it will slow down the system, even if it don't. :P

it's m$!!! all their billions (40 billion in cash) and they still can't make anything good!

Yes... .net does take A LOT more memory than vb6. Just how the .net architecture is, wasn't meant for old comps or slow ones for that matter.

Ok I ca accept that the GC is an "enhancement", the only thing that is slightly off putting from a software point of view is........

If you have a punter and you have a app that takes up 4.5mb in memory........... try convincing him that the .Net version that uses 4 times as much memory is actually a good thing :)........

Also... if when in minimised mode the memory is released because the GC decides it doesnt need it...... then why doesnt it claim it back when you maximise the form?????

Just seems a bit "flakey" to me.... at the very best.. inconsistant.

Regards

You can contact MS about it, but you will get the same answers. If you don't like how it performs, you can still develop apps with VB6 or any other non .Net language. No one is forcing you to develop with .Net.

Here are some links to learn more about the GC:
http://msdn.microsoft.com/library/de...collection.asp
http://msdn.microsoft.com/library/de...management.asp
http://www.fawcette.com/vsm/2002_12/...atures/balena/

Yeah right... thats the attitude.........

Basically you are saying "if you don't like it sod off"

Great post, you gotta be proud!

Not proud, just telling you like it is. I gave you a bunch of links for you to read up and understand the GC in .Net. If you choose to learn about it, then great. If you don't, it isn't going to hurt me either. I am not trying to be a a$$, I am trying to tell you the straight up truth. There are down sides to almost every language, if not all. It is our jobs as developers to either work with that language and it's quirks, or move on to another that fits what we need at the time.

If your paticular app is using too much ram because of the GC and how it operates, then you might want to look into using something like C++. You will cut down on the memory used by a good healthy margin (but you might have memory leaks). Also you said that in VB6 you didn't have a problem with it, maybe this app your creating would be better suited with VB6.

If you think that something specific is wrong, post your code, let is look it over and see if it is doing the same thing on our machines. We may be able to figure out your problem and a solution, we might not.

I did learn about it (its not rocket science).

"If your paticular app is using too much ram because of the GC and how it operates"

You see you even state the problem yourself and you are promoting the GC! You say "TOO MUCH RAM". Which to me is the point....

"Also you said that in VB6 you didn't have a problem with it, maybe this app your creating would be better suited with VB6."

Hold on.. so what you are saying is that The Development environment that is "all singing, all dancing" is useless unless you have 2gb of memory? in all other cases you should probably use VB6?? I don't think MS would agree with you there.

In this case is there EVER a time to use 4 times more memory than needed (vb.net)???

My point is that I think that there is something definitely wrong with the GC. To be able to remove 9.5mb of memory usage by just minimising the main screen then maximizing it cannot be right, no matter how you flower it up. Surely the GC would claim the memory back as soon as the page was maximised again??? (if it needed it) So if it doesnt... does it REALLY need it?

I'm sorry but for any programmer worth his salt, the GC has a major flaw in it.

Regards

Quote:

---

My point is that I think that there is something definitely wrong with the GC.

---

I do understand what your saying. You think that there is a problem with the GC. I do get that.

I liked this statement:

Quote:

---

I'm sorry but for any programmer worth his salt, the GC has a major flaw in it.

---

So your saying that all those people at MS suck at programming because it is they who believe that the GC is awesome. That is funny. There may be flaws in the GC, but none are major from my perspective, so I guess that I am not worth my salt, as you say it.

Anyway, did you read and understand this about the GC, it is from the MSDN site:

Quote:

---

When you initialize a new process, the runtime reserves a contiguous region of address space for the process. This reserved address space is called the managed heap. The managed heap maintains a pointer to the address where the next object in the heap will be allocated. Initially, this pointer is set to the managed heap's base address. All reference types are allocated on the managed heap. When an application creates the first reference type, memory is allocated for the type at the base address of the managed heap. When the application creates the next object, the garbage collector allocates memory for it in the address space immediately following the first object. As long as address space is available, the garbage collector continues to allocate space for new objects in this manner.

Allocating memory from the managed heap is faster than unmanaged memory allocation. Because the runtime allocates memory for an object by adding a value to a pointer, it is almost as fast as allocating memory from the stack. In addition, because new objects that are allocated consecutively are stored contiguously in the managed heap, an application can access the objects very quickly.

---

Look this is my last post here. You may be right. There may be a flaw in the GC....great, did you contact MS about it? Submit a bug report for it? From everything I have learned about it, the GC is working normally. Good luck in solving your problem.

Can we just get back to writing code and stop arguing:D.

Imogen, all hellswraith was doing was trying to help out. I dont think he meant anything bad by telling you to use another language if .NET could'nt prove what you wanted.

Now lets all just get along. We are all here for the same reasons and thats to learn. :D