Editing features very slow

[JoeMadrigal]

I'm looking for a way to save feature attributes a fast as possible.  The two methods I have tried are pretty slow.  I have a feature dataset in a geodatabase (also tried shapefile) that I am applying a spatial intersect and editing those features that fall in my polygon.  I have tried the EditOperation and also the Inspector shown below.  I'm editing (changing attributes) over 27,000 features.  The modifyoperation takes 10 minutes and the Inspector code takes 23 minutes, which both seem way to slow.  I'm doing this in release mode (debug mode takes way too long).

// Using Edit Operation
var modifyOp = new ArcGIS.Desktop.Editing.EditOperation();
modifyOp.Name = "my edit";

// Create an extent rectangle
SpatialQueryFilter spatialQueryFilter = new SpatialQueryFilter
{
    FilterGeometry = CreateDomainPolygon(X, Y, length),
    SpatialRelationship = SpatialRelationship.Intersects
};
using (RowCursor fCursor = pFClass.Search(spatialQueryFilter, false))
{
    while (fCursor.MoveNext())
    {
       using (Row row = fCursor.Current)
       {
            nameVal = (string)row.GetOriginalValue(nameIndex);
            modifyOp.Modify(row, "fieldName1", dict[nameVal]);
            modifyOp.Modify(row, "fieldName2", dict[nameVal]);
       }
    }
}
modifyOp.Execute();

// Inspector inside rowcursor (slower!)
using (Feature pFeature = (Feature)fCursor.Current)
{
    nameVal = (string)pFeature.GetOriginalValue(nameIndex);
    insp.Load(pLayer, pFeature.GetObjectID());
    insp["fieldName1"] = dict[nameVal];
    insp["fieldName2"] = dict[nameVal];
    insp.Apply();
}

 I am wanting to get these down to a minute if possible.  Is there a faster/better way to edit feature attributes?

[MK13]

@CharlesMacleod @UmaHarano  @RichRuh  do you have any insight into this? I am having extremely slow performance as well (over 1 hour), with an edit operation like he has in his code sample, in an attempt to update a field's values in an enterprise sde feature class.

[JoeMadrigal]

I did not find a way to improve the speed with the SDK.  I had to write an external C++ GDAL library to do the same thing in just seconds instead multiple minutes or hours.

[MK13]

Huh! Is it supported by esri? Do you mind sharing how you did it? @JoeMadrigal 

[JoeMadrigal]

I'm more than willing to use the Pro SDK, but didn't get any responses or help.  Go to gdal.org and look over how to manipulate features and their attributes (check out the vector API tutorial) with GDAL.  I used C++, but there are other bindings with Python the most popular, I think.  Just call an external C++ DLL from you C# or build your GDAL code to an executable and call it from your c# if you prefer it that way.

[Kevin_Andras]

This is really disappointing performance. I have been building and using a Desktop add-in that would frequently write thousands to hundreds of thousands of table records quite quickly, and with the impending demise of Desktop I've been translating my code to the Pro SDK.

For example, in a feature class with 16,000 records (fairly small for my typical workflow), a simple field calculation without undo takes about 2 seconds. With undo, and including the save, it takes about 10 seconds.

I can perform EditOperation.Modify (in a loop), which is very fast (1 second); the subsequent EditOperation.Execute takes 1:48, and the SaveEditsAsync takes 21 seconds.

When I modify 3 attributes at once, the EditOperation.Execute time increases to 6:46 seconds.

[Kevin_Andras]

I have figured out, somewhat, ways to improve performance. It is still an order of magnitude slower than ArcObjects, which is going to be a problem for us and our clients (end-users of my add-in).

Since we have no need for any type of undo, I am forgoing the edit operation for the Row.Store() method.

Adding attribute indexes for the fields getting updated speeds up performance a lot. This, as far as I can tell, can be done only using geoprocessing and not via the SDK.

Row.Store() really speeds things up when I need to write to multiple fields - it takes roughly the same amount of time to write to one field as it does three.

Strangely, it is actually quicker to write to a shapefile (dbf table) than it is to a geodatabase (the tables are otherwise identical). Writing 96,000 records to a shapefile took 2:49, while the gdb took 3:34. ArcObjects could write to the same shapefile in about 10 seconds.

Any tips to make this faster (or, improvements in the SDK) would be greatly appreciated.

[MK13]

Unfortunately, one cannot use Row.Store() on versioned enterprise data which is the scenario that I am working with. But I agree, Row.Store() is much faster than EditOperation.Execute().

[Kevin_Andras]

@MK13 - Does EditOperation.EditOperationType = EditOperationType.Short work for your scenario? I was hoping it would for mine - local shapefile or file geodatabase, but it does not.    This stuff is not too well-documented.  

Check out this doc and search for EditOperationType

https://proceedings.esri.com/library/userconf/devsummit-euro18/papers/devsummit-euro_43.pdf

[MK13]

Short wouldn't work for versioned enterprise data since the edits cannot be committed immediately. They have to go on the undo stack. I suspect that the editoperation type is inferred based on how you're committing your edits. For example row.store() would be short since the edits are committed immediately.