I am trying to make the switch to ArcGIS Pro (2.5.1) and am encountering what seem like very slow geoprocessing times. I built a very simple model that iterates through a feature dataset of ~900 feature classes (1 polygon in each) and buffers each one. The new feature class is written to another feature dataset in the same geodatabase.
When I kicked off this process, the iterate was taking ~6 seconds and the buffer took ~12. The process has been running for about 21 hours now and gotten through 600 feature classes, however the geoprocessing time has increased significantly. The iterate has stayed consistent, but the buffer operation now takes ~33 seconds!
I know there are faster ways to do this; my computer is a bit older (i7-6700 3.4 GHz, 32 GB RAM, 64 bit) and the data are stored across the network.
Overall, geoprocessing has seemed noticeably slow in Pro compared to similar operations in ArcMap. I haven't gotten to benchmark these tasks in ArcMap and don't have time to open a support ticket right now.
This post is not about bashing Pro, I'm just wondering if others have experienced this and what can be done to avoid it?
probably running out of memory and everything is getting swapped out to disk.
Turn on your windows system monitoring and monitor your memory usage and disk activity
Thanks for the response Dan. I checked and the memory is staying consistently at 25% and CPU is hovering around 20%.
It doesn't seem like my system is really being taxed by this.
Here is a shot of my Memory resources:
It seems like there is lots of free memory. Any thoughts?
Are you working from a file geobatabase on a network share to perform this processing? If so, can you copy the data to a local drive on your machine and see if that speeds up performance?
Although this occurred with ArcMap geoprocesses, I found that models/scripts that used to work fine over the network were now error prone and the issues were resolved by performing all the intermediate processing on a local drive.
Yes, this processing is occurring across a network share. The process has been going for over 24 hours now, so I think I will try and wait it out. It didn't even cross my mind that it would be this slow so I did not attempt any optimization. Ruling out network issues is a good idea; I hope that it is not a problem inherent with Pro as it is definitely not feasible for me to bring all my data local for processing.
I was thinking the same thing as Michael Volz.
Is the source a file geodatabase or an enterprise geodatabase?
If it is a file geodatabase, I would try running it with the fGDB source locally to rule out any network related items.
If an enterprise geodatabase, I would look at what the resources on that machine are? What is the RDBMS being used?
I wasn't able to tag you in my response to Michael, but this is a fGDB across a network share.
If this finishes, I will attempt to move things locally to finish my processing chain which involves extract by mask, raster to points and topo to raster for each of these buffered areas.