Why is ArcGIS Pro so slow?

61927
106
02-08-2019 09:57 AM
ClintonJenkins1
New Contributor II

I like ArcGIS Pro. It is clearly a step forward in many ways. But why is it so slow for what are very simple things that should be nearly instantaneous. For example, if I want to adjust the symbology of something, ever single step causes the program to whir and think for about ten seconds, even when the layer is turned off! What exactly does it have to think about when the layer is not even rendering?

Almost every action in the program seems to generate some unknown processing demand. I can understand if the map is updating or a tool is running, but it seems to be for everything. This really drags down productivity and leaves me frustrated. If it wasn´t for this, I´d probably start switching to Pro completely. With all these lags though, it is impossible.

None of the data are on the network. Windows 10 machine, 32GB ram, fast video card not even close to maxed out. Most data are on SSD drives. 

106 Replies
TroyBum72
Occasional Contributor

Does anyone remember how slow ArcMap used to get, and one of the primary ways to reset it was to rename the Normal.MXT to _OLD, or just delete it and make ArcMap re-create at next run?  Here are some items I have found recently that are very similar to that and seem to improve performance, at least initially right after deletion.  Hope this helps.

DELETE THESE FOLDERS:

  • %userprofile%\AppData\Local\Esri\                          the folders Local Caches and Index
  • %userprofile%\AppData\Local\Esri\ArcGISPro       the folder rest_locator_cache
ScottFedak2085
Occasional Contributor

Awesome suggestion @TroyBum72, thanks! After setting those files to _OLD and letting Pro re-build upon a restart, the slow Notebook / Python issues I was running into went away. The createFeatureclass issue reverted back to only taking 1.27 seconds to complete and I was not seeing all the objects being opened and closed in the Diagnostic Monitor. We'll see how long it lasts, but at least I have a solution going forward.

This did not appear to impact the more routine tasks like object deletion. The Diagnostic Monitor still demonstrated that Pro appeared to be iterating over every object in my project, opening the object, apparently iterating over the contents of that object as the elapsed time appeared to be larger for larger files, and then closing the object. It also appeared to have done this multiple times per object.

0 Kudos
TroyBum72
Occasional Contributor

great, so glad it worked for you.

0 Kudos
JakubSisak
Occasional Contributor III

Excellent suggestion and makes sense. There seems to be a noticeable improvement in basic editing and overall performance. Thanks @TroyBum72 

0 Kudos
TomKukitz
New Contributor III

Hi Troy!

Wow I did the same thing and it's much faster, but still slow as software goes. I had an inkling it was the cache slowing it down. The cache keeps piling up and it drags performance way down. Local Cache now OLD was 8.7G. The rest_locator_cache was only 3 MB though. But the Local Cache needs to be flushed once in awhile. I remember arcmap having such an option I think. Great find though! Esri should put a flush option somewhere.

TomKukitz_0-1685032584403.png

 

I am pretty old and when an old guy says software is too slow, believe me it's too slow! LOL!

Tom

KoryKramer
Esri Community Moderator

There is an option to clear the cache manually, as well as an option to have the application do it every time it closes: https://pro.arcgis.com/en/pro-app/latest/help/mapping/properties/display-options.htm#ESRI_SECTION1_C...

KoryKramer_0-1685032966535.png

 

TroyBum72
Occasional Contributor

yeah....starting at 3x.  Thanks for pointing that out Kory.  The clearing cache by the "now" option does only clear out 2 of the folders:

\AppData\Local\ESRI\Local Caches\MapCacheV1

\AppData\Local\ESRI\Local Caches\BmLCacheV2

I am recommending you dump everything in \AppData\Local\ESRI\Local Caches

0 Kudos
TomKukitz
New Contributor III

Thanks Kory, this will definitely work for me!

TroyBum72
Occasional Contributor

That's a great way to look at it.  Same for me! HA  Since this, we had a new development.  One thing that was slowing us down with feature services was with some caching of domains.  Sometimes that would time out, or take nearly 1 minute to resolve.  Working a case with ESRI we found that just switching that rest call (just for queryDomains https://OURSERVER/WEBsrv/rest/services/LANDservice/LANDfeatures/FeatureServer/queryDomains) to forward over to the MapServer version - things worked fine.  Fast, data and features were still coming through.  But turned out - we had a user somehow load over 90k domain values on a single field in a feature class.  Now that's one heck of a pick list!  I say all of this to close out this particular thread with the knowledge (at least at my company) that 99.32641% of the time a performance problem has a data problem feeding it.  Whether it be sharing shapefiles, bad mapped network drives in a virtual setting, super large publish/copy fGDB to hosted services, or bad rules like 90k domain values, you can fix the data, fix the problem.  We have to be very wholistic in our approach when we get complaints like "ArcGIS Pro has been sluggish all day, and others on my team are saying the same thing".  Usually ends up not being Pro at all so if you clear that old cache, and still have major headaches, start looking into your data.

Not everyone can go to ESRI for a case, and yes here - we were looking at domains and completely missed 90k on a single FCs field for some 6 months with a work around.  Finally our DB crashed with a patch and we found multiple issues once we fixed this data problem.  We're humming well right now, so well we are thinking of upgrading to 11.1.  May as well start over again!  🙂

The slow queryDomain return was found because of the Diagnostic Monitor Ctrl-Alt-M.

Thanks for commenting!

SimonSchütte_ct
Occasional Contributor III

Also, if you have many external Services (WMS) in your map, loading them can drag down the performance significantly. We had a case, where 30 WMS Services were in the map TOC, most of them disabled from showing in the map. However, looking at the ArcGIS Pro Diagnostic Monitor we noticed all WMS services  and all data references were loaded/requested by ArcGIS Pro on Project startup, even if they were disabled and not rendered in the map. Removing all of those unused WMS services and replacing them with WMTS where possible,made the project loading time 10 times faster.