Why is ArcGIS Pro so slow?

63711
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
JakubSisak
Occasional Contributor III

Fast forward to October 2021 and version 2.8.3 and what the OP mentioned still remains an issue "every single step causes the program to whir and think for about ten seconds"  There are so many mysterious processing delays constantly stalling simple processes and hindering productivity I still often resort to getting things done in ArcMap instead.  Also random rendering issues make it seem that processes did not complete correctly. With time I learnt to close and open map or the application to render results in maps correctly but it's really really frustrating... 

randallhergert
New Contributor

Same issues ever since changing to ArcGIS Pro 2.7 and 2.8. Lowering the antialiasing and switching to OpenGL and clearing the cache have worked in the past. But old slow down issues have cropped back up again. Deleting featureclasses take 10-15 minutes, any edits can take the same amount of time even if it's a simple text change in one row. A script tool that relies on a few editing commands used to take 3-7 mins in ArcMap, now can take as along as 2 hours or more to complete. I love the new user interface and operability of Pro, but these slow downs for basic, and I mean BASIC functions make this program nearly unusable. System settings all match with 32GB RAM and x64 bit processing and it's the only program running. 

JLyon
by
New Contributor III

No idea what the new updates are doing but ArcPro is regressing now, simple select features taking 1-2min, merges, splits that take 10 secs in ArcMap taking 2mins+ in ArcPro. Have done all the other trial and errors to fix issues, running all data locally on SSD. Loving the use of ArcPro but hate the loss in efficiency. 

KoryKramer
Esri Community Moderator

Hi @JLyon Sorry to hear that - it obviously isn't normal or expected.  If you have already run through Troubleshooting Performance Issues in ArcGIS Pro with no resolution then it would be time to work with Technical Support.

0 Kudos
JakubSisak
Occasional Contributor III

I find that a project gets increasingly slow the more maps and layouts are added whether these are open  in tabs or not.  My recent crude workaround around these issues (though no workarounds will make Pro as responsive as ArcMap) is to create a temporary project with only a simple single map with 1 or 2 layers in which I do all my editing and other work.  This includes things like clipping and splitting features. Not perfect but better. 

MahmoudAbdulrahman
New Contributor

I have the same problem in ArcGIS Pro 2.9, i discovered that using ey SSD external hard drive for sourced data is the main reason.

even though my SSD is extremely fast, it seems that ArcGIS pro has issues regarding external hard disks source data

0 Kudos
by Anonymous User
Not applicable

I have some data layers linked to external drives and even when those are switched off (not ticked) in data of content, it makes the performance of ArcGIS Pro extremely slow. For example starting takes about 20 mins, so if my session crashes, have to wait 20 mins (( How can I disable connecting this layer to that external source to prevent such slow-down? I don't want to delete it, because those are my live data and I keep taking snapshot of those data and export it locally 
Thank you!

0 Kudos
TroyBum72
Occasional Contributor

If shapefiles, they will be slow.  Convert to fGDB.  If shared with others, there may be contention.  If you use a virtual processing environment, and you are using mapped drives, I can provide some very detailed performance help.  That is how we work, and referencing a mapped drive that is on your PC through the virtual environment is an incredible performance killer, yes, sometimes when the layers are "ticked" off.

ScottFedak2085
Occasional Contributor

I will preface this with the fact that I often do testing in big project folders where I just keep adding, iterating through ideas etc. and don't recall running into slowness issues with smaller projects.

In Pro 3.0 we seem to still be seeing these long runtimes for seemingly simple tasks like object deletion, name changes, etc. I also just ran into a significant slowdown of a notebook I was working with that had been functioning fine prior. A createFeatureclass cell that was running almost instantaneously now will take almost 2 minutes and a big long cell of a bunch of AddField operations takes forever to run.

During this process, I decided to open up the Diagnostic Monitor and noticed that the Main CIM worker thread was iterating through every object in my database connections several times and opening / closing the dataset for some unknown reason. Maybe there is a more advanced programming reason for seeing this behavior like backup management if an error is produced, but these datasets were in different databases and completely unrelated to the current task. I saw the same behavior just when deleting a Feature Class (see the screenshot below, also attached). All those dataset objects listed are not even in the same database as the Feature Class that was deleted. Not sure if this is useful information, but seemed like odd behavior to observe. 

ScottFedak2085_0-1677711559341.png

 

0 Kudos
Lake_Country_GIS
Occasional Contributor

I've experienced the same behaviour. I'm thinking that common tasks like these are no longer part of the QA regression testing on ESRI's end, therefore are over looked.

0 Kudos