|
 Sounds even worse than I thought! If they had to pull that trick to get this crap to work, you know they're patching around their own design flaws. I wish you luck with this one. I don't know how to get around this one.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I'm able to contact them and ask for help, and they have been very helpful. But yeah, I would not have set it up like this, that's for sure.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
WIll GC only fress memory if there are other apps which needs more memory.
If there is enough free space it will not free memory. Is it right.
|
|
|
|
|
Gosh - didn't I just answer this ?
In my experience, GC can be slow to occur if you don't force it, and yes, the thing that forces GC is the fact that your computer has no memory options left at all. Or you can force it yourself. This is a bad idea, you should just manage the items that you think can cause a problem. Basically, if you deal with large objects like bitmaps, you need to manage your own memory, just like you did in C++.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Ok. But I can force GC by GC.Collect().
Thanks
Devin.
|
|
|
|
|
Yes, if you must. I would not recommend it though, you could hurt performance by causing the GC to run more often than it should. Just dispose of objects that you'd like collected.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Thanks this helped me a lot.
Devin
|
|
|
|
|
The GC runs on it's own internally managed schedule, not necessarily only when memory starts to run low. Other factors also influence when the GC occurs. If you release lots of small objects all over the managed heap, the GC will run earlier than scheduled so it can compact the memory to make room for larger objects and/or prevent memory fragmentation. This is only one small sample of how the GC manages memory collection.
If you really want to learn the in's and out's about how the Framework manages memory, object creation/destruction, object lifetimes, how unmanged memory fits into scheme of managed memory, ..., check out this[^] article index on MSDN.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
As an aside I have found I can make much memory savings by reusing objects. Performance can go through the roof when doing that as well - or at least it did with me.
|
|
|
|
|
My apps performance improved, my own personal performance remained much the same 
|
|
|
|
|
Can I Set an object to null in the middle of the method, when I found that I I am done using it. Will I achieve performance.
|
|
|
|
|
No, you'll simply lose that reference to the object. The garbage collecter is in charge of when it's actually deleted, and either way, there's no performance gain, unless your object is big and you're chronically short of memory ( call the objects Dispose method if this is the case, for example if you deal with images in memory ).
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
1)
But I am helping the GC telling the object has no reference, instead of GC finding itself. Is I am not gaining the performance?
2)
So I can set a large object to null to achieve performance gain
|
|
|
|
|
devin123 wrote:
But I am helping the GC telling the object has no reference, instead of GC finding itself. Is I am not gaining the performance?
You're telling C# that this reference to the object is no longer required. At some point, sometime before your PC totally falls over from lack of memory, the GC will work out that no references are held, and so do garbage collection. I found out the hard way that managed DirectShow leaks memory ( I was loading video files ), and my app was running at a crawl as my memory was full and my disk drive was swapping non stop. GC had not occured.
And why would you gain performance from getting back some memory, unless you have severe memory issues already ?
devin123 wrote:
So I can set a large object to null to achieve performance gain
No, you can Dispose of it to free the memory, and then set it to null. The setting to null is actually irrelevant to performance or memory usage, it's just good coding. This will help if you're in a situation like my example above. You should do this when you have large memory objects flying around, but it will only help performance if excess memory usage is hurting it.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
But dispose only releases the resources, it does not reclaims the memory.
|
|
|
|
|
I've done this, and I can assure you, it causes the memory to be released, if right away, or through encouraging the GC to release the object, I don't know. However, setting a reference to null definately doesn't do this, and will not help you in any way.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
So you meant to say that using dispose, we can manually reclaim the memory and also the resouces
|
|
|
|
|
GC reclaims memory, but calling Dispose seems to give it a serious hint, or otherwise, the Dispose methods for bitmaps and movies free the memory in some other way.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
So dispose does not directly reclaims the memory. It helps GC in more efficient GarbageCollection
|
|
|
|
|
That would be my guess. What I know for sure is that if you call dispose, you'll find your memory situation does not deteriorate where you use a lot of large objects.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Thanks Christian, for your help.
Devin
|
|
|
|
|
The dispose pattern if implemented correctly should supress calling the finalize method of the object. The GC when collectiong objects always calls the finalizer of these objects, but if dispose is implemented and the object has been disposed, u might gain this small advantage in performance allthough its probably insignificant.
The main advantage is as been stated before, the release of unmanaged resources and the fact that ur helping the gc manage memory in a more efficient way.
|
|
|
|
|
Here is how it works:
you have a reference to your ".net" object instance
the memory that object occupies is released by the GC when no references are left.
Dispose is used to release native resources , such as filehandles , db connections or memory allocated by some native resource.
so ".Dispose" does not kill the .net object itself , it just tells it to drop its expensive resources.
if you are working with images , eg in DX there are plenty of unmanaged resources behind the scenes , and your .net object is told to drop those directly ... therefore Christian get a big chunk of memory back.
if your object does not hold any references to any native resources (directly or inderectly) you will not gain anything by implementing idisposable on that class.
eg if your class has a big arraylist or array and you set it to null in your dispose method , you will not gain anything since those are managed resources taht will be released by the GC.
//Roger
|
|
|
|
|
I am trying to convert the following code to C# and am having quite a bit of difficulty.
#ifndef API
#define API
#define API_Item 256
Here is what I tried:
#if (!_API)
#define API
public static readonly int API_Item = 256;
Am I way off?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
