topic Re: release com objects? in ArcObjects SDK Questions

release com objects?

SantoshV — Wed, 16 May 2012 12:54:53 GMT

Hi,
I have developed a tool in arc-objects on Visual studio 2010,
the tool works fine but once installed my Arc Map drawing the map(refreshing) and printing slows down..
I have used ITopologicalOperator in the program

Should I release any com objects here if yes what object should I release

Please guide

Re: release com objects?

DuncanHornby — Sat, 11 Dec 2021 23:42:40 GMT

Santosh,

Without seeing your code its hard to know why it should slow down. I know it's good practise to release cursors. Below is some example code on how I release a cursor, but your slowing down may be nothing to do with memory consumption it could be poor logic like creating the same object every time in a loop when it needs only to be created once (e.g. a spatialfilter object)?

' For ArcGIS 10 using VS 2010 you need to import the following
Imports ESRI.ArcGIS.ADF.Connection.Local
Imports ESRI.ArcGIS.ADF
 
Dim pQueryFilter As IQueryFilter 
pQueryFilter= New QueryFilterClass
pQueryFilter.WhereClause = "ID = 1"
Using releaser As New ComReleaser
 Dim pFeatureCursor As IFeatureCursor
 pFeatureCursor = pFeatureclass.Update(pQueryFilter, True)
 releaser.ManageLifetime(pFeatureCursor)
 Dim pFeature As IFeature 
 pFeature = pFeatureCursor.NextFeature
 While pFeature IsNot Nothing
 ' Do something with pFeature
 pFeatureCursor.UpdateFeature(pFeature)
 pFeature = pFeatureCursor.NextFeature
 End While
End Using

Duncan

Re: release com objects?

BennettChamberland — Wed, 16 May 2012 21:19:37 GMT

For the most part you shouldn't have to. ESRI objects will generally selfdestruct nicely when the function/scope gets closed. I would check the logic and make sure the process ITopologicalOperator is performing, is working only when wanted.

Re: release com objects?

RichardWatson — Sat, 19 May 2012 10:39:03 GMT

.NET automatically releases objects when they are no longer used. This is called Garbage Collection (GC).

One issue with this is that the mechanism has to have some sense of pressure, i.e. how much does a given object cost. When everything is pure .NET it works great. When you throw COM interop into the mix it works less well. Essentially you have a small .NET object referencing a COM object in a black box, i.e. the system has no sense of pressure. This creates a pain point that Microsoft did not design the automated machine to handle well.

Cursors are particularily sensitive. If you are ripping through these (and they are private) then you need to be explicitly releasing them.