topic Re: Performance of geoprocessing in ArcGIS Pro SDK Questions

Performance of geoprocessing

jackpearson — Mon, 03 Jul 2017 15:28:26 GMT

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?

Re: Performance of geoprocessing

CharlesMacleod — Mon, 03 Jul 2017 19:17:50 GMT

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

Re: Performance of geoprocessing

jackpearson — Fri, 07 Jul 2017 12:14:41 GMT

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

Re: Performance of geoprocessing

SusanFarley — Mon, 29 Apr 2019 13:04:06 GMT

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.

Re: Performance of geoprocessing

NobbirAhmed — Thu, 02 May 2019 21:34:14 GMT

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.

Re: Performance of geoprocessing

NobbirAhmed — Thu, 02 May 2019 21:35:08 GMT

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

Re: Performance of geoprocessing

AdamDavis — Mon, 10 Jun 2019 11:37:26 GMT

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

Re: Performance of geoprocessing

SusanFarley — Mon, 10 Jun 2019 13:26:35 GMT

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()));

}

Re: Performance of geoprocessing

NobbirAhmed — Mon, 30 Sep 2019 16:24:25 GMT

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.