Performance of geoprocessing

[jackpearson]

I am building an add-in for pro using pro sdk 2.0; The add-in reads a specific funky formatted file of point data, creates as point feature layer in local file gdb and symbolises as a feature layer according to metadata in source file;

All working, but users complaining that it's pretty slow : (1k points taking over 40-50 secs on a reasonably powered development machine)
So I want to check whether there is a better approach than this one that I am taking :

1) Using : Geoprocessing.ExecuteToolAsync("CreateFeatureclass_management"...) to create the new, empty feature layer
Time taken : 13-15 secs

2) Add 6 fields to the schema using : Geoprocessing.ExecuteToolAsync("AddField_management", args);
Time taken : 15+ secs

3) Add point features and populate attribute values for 1k points, 6 attributes
Time taken : 2-5 secs

4) Apply unique value based Symbology
Time taken : 2-4 secs

The schema & symbology change with every import so template layers not a solution.

Any ideas?

[CharlesMacleod]

Hi Jack, you may have better luck with this question in the Geoprocessing forum: https://community.esri.com/community/gis/analysis/geoprocessing

[jackpearson]

Hi Charles - Any idea if anyone at Esri can help me with this ?

[SusanFarley]

We are having the same issue. Has there been any sort of resolution? It is taking 5 seconds to call one instance of Geoprocessing.ExecuteToolAsync("AddField_management", args); on a node. I takes a little over 1 second when calling it on a link. 

[NobbirAhmed]

This is interesting - we will look into this and post back.

[NobbirAhmed]

Instead of calling Add Field 6 times you can call the new tool (only in Pro) Add Fields (multiple) once to add as many fields as you want. It'll create only one call.

https://pro.arcgis.com/en/pro-app/tool-reference/data-management/add-fields.htm

A geoprocessing tool has the benefit of taking care of some underlying validation and error checking tasks. The cost is time - it may take little extra time in doing so. For example, you are calling Add Field  - such as, data validation, You are calling course-grain Geoprocessing tool multiple times. Calling Add Field 6 times will need 6 validate/error checking and so on. 

In such cases, you can use fine-grain functions of Geodatabase library - starting from building the schema and so on. That'll be much faster.  

[AdamDavis]

Hi Ahmed,

I was not aware you can create field in the Geodatabase library. Could you provide an example please?

I thought all creation of feature Classes  / Fields was through the geoprocessor.  It's why we use the standalone File Geodatabase API where we can as it works way, way faster and is a more "natural" way to make things.

Thanks,

Adam

[NobbirAhmed]

Hi Adam,

Yes, using Geodatabase API is faster - however, you'll need a deeper understanding of the geodatabase API and you'll have to handle the error checking and validation.

Geoprocessing, however, has one simple approach for any tool execution. Executing via Geoprocessing API is slower than calling the fine-grain API because it calls the underlying geodatabase API. The major benefit of using GP is that you won't have to worry about validation of inputs and output - the gp framework does validation and return appropriate messages.

[SusanFarley]

Sorry for any typos, but am retyping from code:

public async Task AddFields (string path, Dictionary<string, AttributeTypeNames> fields)

{

   string fieldNames = "";

   foreach (KeyValuePair<string, AttributeTypeNames> item in fields)

      fieldNames = String.Format("{0}{1} {2}; ", fieldNames, item.Key, item.Value);

   List<object> args = new List<object>

   {

      path,

      fieldNames

   };

   IGPResult res = await Geoprocessing.ExecuteToolAsync("management.AddFields",

               Geoprocessing.MakeValueArray(args.ToArray()));

}