Why does ArcGIS Pro have to be so slow???

[ericmeyers1]

Why is ArcGIS Pro so slow? To select assets, field calculate, display layers, change symbology... the easiest of tasks that are commonly utilized within ArcMap are a drag on the software.

When will ArcGIS Pro become faster than ArcMap? That will be the day it could replace it as the goto product for GIS professionals.

[MattWilliams5]

Wanted to add my two cents since this thread still seems somewhat active and I have not seen a solution anywhere that solved my “Why is everything so slow?” performance issues. In my case, it turned out to be OS settings.

I added ArcGISPro.exe process and common ArcGIS file types to Exclusions in Windows Defender. This solved the biggest issue of AntiMalware Service Executable sniffing and dramatically slowing down all incoming and outgoing connections. This helped performance especially for network hosted datasets. [Windows Defender Security Center > Virus & threat protection settings > Add or remove exclusions] You might have a look at other antivirus/malware software that could be scanning files actively used by ArcGIS Pro and add exclusions there as well.

Next up was graphics performance. Downloaded and installed latest drivers for graphics card directly from manufacturer. Windows update was not automatically updating for me. Set graphics settings to “High Performance” for the ArcGIS Pro application. This will make sure graphics processing is done by graphics card if available, rather than CPU.

For other laptop users, you should see a slight improvement when setting power mode to “Best Performance”. Not sure if this is an option with desktop version of Windows 10.

This won't help every case, but might be a good place to start if these settings are at defaults.

[ThomasColson]

For most organizations, excluding anything from security controls is not an option, and not something that had to be done with ArcMap. We have the same AV problem with ArcGIS Server: AV scans of the install directory slows it to a crawl. 

[DevinLavigne]

Thanks Matt. Never thought of this. I'm going to give it a try.

[DuarteCarreira]

I've been looking at pro for the last years. Always same conclusion: that it is too slow (mind-blowing slow). I remember going from arcview 3 to arcgis, and this is not the same user resistance issue.

As an arcmap user I had the same wish list as everyone else:

- multithread - to speed things up with my multi-core cpu

Result: pro is unbearably slow

- antialiasing - to see things as they print or make better presentations

Result: it does anti-aliasing, but is so slow I can't use it

- 64 bit - I want to use more memory to be faster!

Result: pro is unbearably slow

- several layouts in a project - I want to be more productive, have less projects for a single task

Result: pro is unbearably slow

- cartography/symbology - I want better/more rules so I am more productive and can avoid complex layer/scale range/symbology setups (same layer loaded multiple times, different query defs, scale ranges, symbols)

Result: pro is unbearably slow

So the result is - I can't get the good stuff that would make me abandon arcmap. As time passes and arcmap gets further behind I'll be looking at the competition for a new best-in-class GIS desktop product. I already found one that offers all of the above items (QGIS). If esri doesn't/can't make a good product I will move on. I'm a client, I am not a fan. I owe you money not loyalty. You owe me quality service.

[VladimirStojanovic]

Thanks @Duarte Carreira for this post. I was already thinking I am alone. I would like to write a post on my own, but there are so many things I would like to address about this sloppy thing called ArcGIS Pro, that I simply cannot find the time for that.

Unfortunately, ESRI is completely wrong in so many ways related to this issue and they whether don't get it or don't want to get it. It is really pitty.

[RickGonzalez]

Wow!  And to think, they will keep peddling Pro at the ESRI User Conference as if it was the best thing ever.  I laugh at them the last time I attended UC when they smiled and smirked about its 64 bit capability.  No, Mr. Dangermond!  It's a useless product!  Maybe we need a quiet revolt at the UC and say enough is enough; challenge the presenters and developers on its lack of performance!  ESRI, please take back Pro and keep ArcMap!

[DanHoffman1]

Hello,

I want to re-iterate what Michael Volz just replied.  I had opened a ticket last month with ESRI Premium tech support, and used the ‘Select By Location’ tool as an example in that case. The simple selection I was doing was selecting the parcels on a remote SQL Server with one district polygon – ultimately selecting a subset of about 200 parcels. In ArcMap this operation takes about 1 – 2 seconds, but in Pro it took over 8 minutes on my end. Thankfully ESRI could reproduce the error (faster than 8 minutes, but still unacceptable) and the results are below. They have logged it as a bug and will send it on to development. The issue seems to be working with any remote database….Pro is very chatty and slow in that regard.

Overall, I like using Pro and use it everyday, but I agree that the performance needs work still, and this issue is preventing us (LA County) from fully switching over.  Like has been said earlier in the string of this post, if we all work with Tech Support on different Geoprocessing tasks then they will get a loud and clear message that the software needs further configuration.  This Select By Location task was just one example, I've had performance issues with joins, exporting to excel, spatial joins and other fairly straightforward Geoprocessing tasks.

From ESRI…

File Geodatabase: – ArcMap 10.6.1: Less than a second. – ArcGIS Pro 2.2.4: Less than a second. – ArcGIS Pro 2.3 Beta: Less than a second.

SQL Server: – ArcMap 10.6.1: Less than a second. – ArcGIS Pro 2.2.4: 3 minutes, 45 seconds. – ArcGIS Pro 2.3 Beta: 3 minutes, 9 seconds.

Oracle: – ArcMap 10.6.1: Less than two seconds. – ArcGIS Pro 2.2.4: 3 minutes, 57 seconds. – ArcGIS Pro 2.3 Beta: 3 minutes, 25 seconds.

PostgreSQL: – ArcMap 10.6.1: About 3 seconds. – ArcGIS Pro 2.2.4: 1 minute, 43 seconds. – ArcGIS Pro 2.3 Beta: 1 minute, 3 seconds.

Thanks,

Dan

[MichaelVolz]

Dan:

I'm not sure you have data that can be tested like mine, but I have a bug created for SDE performance in Pro for a specific scenario (no editing involved which is even slower) that you can try replicating with your data.

I have a fairly large feature class with about 28,000 records that has a relationship class to a table with about 5,000 records.  One of my auditing steps to find orphan related records is to select all the records in the feature class and then open the related table where it would have all the related records selected.  Any unselected records are orphans.  This operation can take anywhere from 20 - 50 seconds in ArcMap 10.5.1 but consistently takes 3 - 5 minutes to execute in Pro 2.2.4.  The bug for this performance issue is BUG-000119165, which if you can replicate then you can ask to be added to this bug.  My hope would be that the more people that can report the same issue to ESRI, the more likely ESRI will attempt to address the issue.

I also hope that whatever ESRI finds to be the root cause of this problem, will dramatically increase the speed of editing SDE data in Pro as well which would be a major step to the adoption of Pro in production for my organization (instead of just being mostly sandbox software).

[DanHoffman1]

HI Michael,

I will try a similar workflow you described when I find time to do so.  It's good to hear that you've logged this as a bug and it sounds like a similar situation to mine.  I share your hope in that more people will report these issues to ESRI and send a message about these performance problems that a lot of us are having.

Thanks,
Dan

[MichaelVolz]

I tried your workflow on my system, but I did not see the drastic performance issues that your data show, so it would be interesting to see how slow my workflow would be on your system.  When you say your server is remote what do you mean exactly?  At my org the servers are located at a remote location, but are connected by fiber so the throughput is very good (I'm not sure of the metric on this though).  How is your remote server connected to your network as this could be part of the issue?