So does implementing Dispose() on the managed objects where would improve Garbage Collector’s performance by getting a hint from the to probably bypass some of its whole process.
I saw this answer on a question which didn’t get high vote but is this true? If yes then how?
No that is wrong. I agree with Aaronaught.
In addition, Microsoft recommends, in a mid 2003 webcast that Don Box presented, that every .Net developer should dispose of their own objects, whether managed or unmanaged, as this improves code performance by anything upto 20%. If done right it can be a substantial performance improvement. So its a core skill that every .net developer needs to know and use.
First off, by calling Dispose methods, it in no way hints the GC that anything special should be done. Dispose is a normal method, like any other.
The magic sauce is what Dispose does, namely releasing resources that are no longer needed.
The #1 rule with IDisposable objects is to call Dispose when you’re finished with them. Yes the GC may eventually clean out memory, but if the objects are still linked to any others that are still in use, they will remain. Dispose also cleans up unmanaged resources, which is crucial, such DB connections, file handles, locks, etc. These definitely need to be closed ASAP.
In short, if you instantiated an IDisposable object, Dispose of it when done.
Yes it has a cost to call Dispose, but as I stated earlier, it means objects can be unlinked from each other, allowing the GC to free them next time it runs. It also means unmanaged resources can be freed immediately. Another win. Memory and resource leaks can cost performance badly, as can application crashes if it gets too extreme!
The developer may have been protecting important resources, so please don’t try to second-guess him!
Profiling is your friend here. If performance of re-creating these objects is a concern, cache them, but still be prepared to dispose of them when finished.