is there anyway to really optimize memory in .Net ?

is there a way to manually deallocate memory ?

otherthan dispose  , what are the otherways we can improve performance ?

i heard setting objects to null will improve memory use . even this wont deallocate memory immediately , the GC has to do the deallocation ?

can we dellocate the memory with out GC like calling delete or free in C++/C ?


all the people talking about memory optimization in .Net , but i dont think the GC gives u any flexibilty in allocation/deallocation to optimize memory .

The .NET Framework provides automatic memory reclamation through the garbage collector. The garbage collector is a low-priority thread that always runs in the background of the application. When memory is scarce, the priority of the garbage collector is elevated until sufficient resources are reclaimed.
Because you cannot be certain when an object will be garbage collected, you should not rely on code in finalizers or destructors being run within any given time frame. If you have resources that need to be reclaimed as quickly as possible, provide a Dispose() method that gets called explicitly.
The garbage collector continuously traces the reference tree and disposes of objects containing circular references to one another in addition to disposing of unreferenced objects.

From the book  "Developing Windows-Based applications with Microsoft VB.NET and C#, Second Edition."

To tell you the truth, disposing does a lot.  .NET comes with a heavy reliance to GC, and honestly, unless you're game developing, the GC usually does a good enough job of keeping the memory usage down to a minimum.  Dispose does reduce the footprint, but you're right, it doesn't immediately delete and deallocate the memory.  Setting the object to null seems to help very slightly as well. 

One thing to keep in mind is that you're running on managed code.  Truthfully, the only times you have to actually take the measures to safely destroy objects the way we know to be true is when you*space
space*into unmanaged code.  Usually, it's done through the destructor ~ClassName, but it's bad practice to use this on straight unmanaged code (learned that one from Ambrose).  If you'd like to do more research on the matter beyond what you can do with .NET's namespaces (GC.Collect - which does cause a halt in thread to complete and should not be used unless completely necessary) read up on how the il is assembled and how it is then compiled into assembly.  In my honest opinion, you're better off just finalizing the objects, and letting the garbage handler do it's job.  

You're right in a strong degree in terms of the flexibility of destroying your memory usage like you could in c++, and one of the benefits I'd like to point out is that a lot of applications went assbackwards because of people handling the memory incorrectly.  The drawback of using a standard approach like GC, you're faced with losing the strength and ability to do it yourself.

Again, if you're eating up that much juice, you're probably either in need of trimming your objects or calling the GC directly.  But if you're stressing over 60k-20megs, I don't think it's much of a problem.  Again, it's all in the application.

I do feel you though.  When I see my applications start eating juice, I get a little devil on my right shoulder that tells me I'm being a bad programmer.

thanks , at last someone accpets setting null has very liitle effect .

eeryone is saying u should set objects to null as if the GC will deallocate immediately after nulling the obj .

anyway the GC has to find other references , before collecting a null object.


but whats the problem , people are expecting .Net memory optimization in a C++ sense . 
like in C++ if u optimize u can really get visible results but with .Net the results are not that visible or even unchanged after what people call optimizations .



so i think there is a new  meaning for the term "optimizing memory in .Net " 

Well, if you look at larger collections, setting objects to null will show some improvement.  However, if you don't dispose, you'll see that memory spike real fast.

Some go so far as to flushing and dropping streams to 0 length before moving on in an attempt to save a portion of a second.  You're right though, with c++, you see a lot more control, and you can see results as soon as you run the application.