|
I have a client who writes software for the vet market. We're integrating his software ( x ray analysis ) with other vet software ( client billing ) and I import their COM objects in order to do this. Now, we've been using a pre release build for me to write this code, and they came out with the release build, and my code no longer works. I replaced the exe with the new version ( the GUIDs should not have changed ) and now the project complains that it cannot find the object to import it. In other words, I need to do a build for each version of the client COM object that exists.
There will be more versions in the future, how do I work my way around this ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
My first thought (granted, not much effort! ) would be to write a shim .DLL for each version of the COM objects that your application calls. The shim should be written to map the calls your app makes to the appropriate COM methods.
But, after more thought, it's getting ugly. Since you don't control the GUID's, ..., oh god, what a mess! A seperate version for each COM release? How often do these updates come out? Call them up and bitch 'em out for not adhering to known good practices for COM programming!
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
It seems that they HAVE such an object, a COM server whose job it is to map to whatever version of the main exe exists. The trouble is, it's not documented, and it seems to require some additional work to do what the underlying methods did all by themselves ( that is, it blows up with errors if I call the methods in the same way, and has some security methods added that don't seem to work the way I'd like in the absence of documentation ). And the code samples they sent me don't use it, which is why I ended up doing it the way I did to start with, I built my code off their samples.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
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.
|
|
|
|