2

I have the following code:

//qf  is a query filter
var fCursor = FC.Search(qf, true);
var feat = fCursor.NextFeature();
int selCount = FC.FeatureCount(qf);
var userId = new int[selCount];
if (selCount != 0)
{
    for (int i = 0; i < selCount; i++)
    {
        userId.SetValue(feat.OID, i);

        **Marshal.ReleaseComObject(feat);**

        feat = fCursor.NextFeature();
    }
    ... 
}   

Does it make any difference if we release IFeature (feat) outside of the loop?

  • 1
    I have to admit I don't know but curious to see what the techies say? I do know that you get a performance boost by setting the cursor to be recycling, which you have done. – Hornbydd Sep 15 '15 at 16:19
  • 1
    As the feature is recycling you should't release it while you're still playing with it... it's one object that (supposedly) gets overwritten as the next feature is called, so if you release it then there isn't an object any more to load the next feature/row into. With a non-recycling cursor each IFeature is a new object and stays in memory until the garbage collector. Does your code work without errors? I'd be surprised if it didn't crash.. – Michael Stimson Sep 15 '15 at 23:06
  • It works fine. "if you release it then there isn't an object any more to load the next feature/row into". I don't understand this part? – Farid Cheraghi Sep 16 '15 at 8:31
2

Forget about releasing an IFeature inside the loop. You can only find performance issues doing that. So I wouldn't recommend to release an IFeature object inside a loop. As Michael says, the objects gets overwritten as the next feature is called. Also an IFeature object isn't necessary to be released (see ESRI documentation about realising in ArcObjects).

I, following ESRI recommendations, release objects that implement ICursors, IEnums and ISets when I've finished to used them. You are also free to release an IRow or IFeature object, but IMHO don't see that necessary.

BTW: A paragraph about recycling and no recycling cursors in ArcObjects (more info here):

Non-recycling feature cursors returned from the Search method MUST be used when copying features from the cursor into an insert cursor of another class. This is because a recycling cursor reuses the same geometry and under some circumstances all of the features inserted into the insert cursor may have the same geometry. Using a non-recycling cursor ensures that each geometry is unique.

  • In the link you have shared, ESRI implies it is better to get rid of any COM object as soon as possible. For example the code snippet releases an object of type IStyleGallery. So I think although it not necessary release the IFeature in the loop but it's better to be released outside of the loop. Don't you agree? – Farid Cheraghi Sep 16 '15 at 9:30
  • As I told you, you are free to release the IFeature object, but I've never do it, and every expert developer that I have found didn't tell me that I was wrong. – Katah Sep 16 '15 at 16:55
  • 1
    No the IFeature is fine, let the garbage collector get it when it goes out of scope. The IFeatureCursor is another story, I'd get rid of that as soon as you're sure you no longer need it - like an arcpy.da.XXcursor it will persist locks on the dataset. If you get rid of it inside the loop then a new feature object needs to be created, effectively turning your recycling cursor into a (mostly) non-recycling cursor and you'll loose most of the performance benefit. I know with IRow.Delete if you use a recycling cursor it will crash after the first delete as the row/feature object is disposed. – Michael Stimson Sep 18 '15 at 0:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.