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

ericmeyers1 · ‎08-01-2017

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.

ThomasColson · ‎07-27-2018

I believe several cases are open on this issue, I have a few myself. Unfortunately we're in "Cannot Reproduce" territory, but discussing at least weekly as we churn through different test and logging methods. Which leads me to: it would really help me, and others having the problem, if you'd log a case and have good steps to reproduce in Arc and Pro that show the same task in Arc not showing the performance issue versus the same task in Pro.

I will say, applying a blanket "Everything is slow" won't get a lot of attention, my cases focus on two very specific tasks, with the idea being that there is one specific cause that will resolve all of them. ESRI has acknowledged "There is no question you're having a problem" based on hours of screen sharing (with one analyst saying "I don't see how you get anything done"). So far we haven't gotten close to the "glaring and obvious problem", so again, if you are having a problem, love to see your details on GN but I'm hoping one day ESRI will call me and say "User so and so submitted this SDE case and we found the problem! Here's the fix...".

1 888 377 4575, Option 2, Option 1, customer #......

MichaelVolz · ‎07-27-2018

Thomas:

Do you have any idea if the ESRI analysts you have been working with think the problem is database agnostic (Does not matter whether its SQL Server, Oracle, Postgres, etc.)? I only ask this because I have logged bugs with ESRI in regards to SDE and Pro that are specific to Oracle. This has also been the case in the past with ArcMap. Bugs that apply across multiple DBMS would probably get more attention from ESRI than bugs that are tied to a specific DBMS.

BrianE · ‎08-14-2018

So the user has to sacrifice display quality in order for Pro to perform normally? Doesnt seem like a realistic solution at all.

Pro runs slower when working on a project on a network. Period.

Even if you lowered the display settings it would still run slower than if you ran the same project locally.

AndrewQuee · ‎08-14-2018

Just in support of your comment if you hadn't seen it already, further up the thread Thomas Colson reported seeing some pretty intensive network usage for simple operations.

As Thomas just discussed general whinging "it doesn't work good" will be passed over by Esri. What we need to do is show provable and replicatable examples of how it does not perform properly in specific cases, and how there is a demonstrable difference between Desktop and Pro in the same operation.

I'm sure Esri is already doing/has done this, but once isolation tests are done, you can get down to specific cases and the parts of the application causing issues can be optimised or fixed. Probably what is happening (or what we often see as GIS developers) is that one minor issue conflates with some other issues and maybe a bug, or sporadic problems with the OS/network/database to create a noticeable performance problem.

What the user sees is "doesn't work/grinds slowly" but actually solving that can be more complicated than just fixing one thing.

KoryKramer · ‎08-15-2018

...general whinging "it doesn't work good" will be passed over by Esri.

Not passed over, just not actionable. General whinging is really frustrating for development teams.

What we need to do is show provable and replicatable examples of how it does not perform properly in specific cases, and how there is a demonstrable difference between Desktop and Pro in the same operation.

Absolutely! This is productive, but admittedly, is the hard part that may (will likely) require time troubleshooting on the user side if we cannot readily reproduce a performance issue from a given description.

We are committed to continually improving performance and we'll be much more successful accomplishing that by working together to get to the cause. Thanks for the balanced assessment Andrew Quee‌

deleted-user-yMSQSHvui0e5 · ‎08-08-2018

Nothing to do with all the network issues, but I've had a pretty good performance boost by turning off all the antialiasing options, and setting rendering quality Low in the Options--Display menu. Might be worth a shot for everyone following this thread.

AndrewQuee · ‎08-14-2018

Thanks for that. I thought those options would depend only on the GPU - I was running 40% load most of the time so I didn't try them. I was consistently CPU bound, pegging it to 99%+ for the whole time.

Worth a shot to test though. If Pro is using the CPU to render graphics and ignoring your video card's capabilities, well that explains a lot, in particular why this thread exists.

MichaelVolz · ‎08-22-2018

I am working to update python scripts run with ArcMap 10.5.1 to python scripts run with Pro 2.2.1. I am noticing output differences from geocoding which will necessitate updating the python scripts and while researching this topic by performing the geocoding process manually in either ArcMap 10.5.1 or Pro 2.2.1, I have noticed that ArcMap 10.5.1 (the old 32-bit software) is significantly slower than the latest and greatest Pro 2.2.1 (new 64-bit software) with this geocoding process.

Starting from a table with approximately 222,000 records I get a geocode throughput of 28 million records per hour for ArcMap 10.5.1, but only 15 million records per hour for Pro 2.2.1. The computer running the Pro software exceeds specs in all areas, so I'm wondering if there is a configuration issue with my geocode setup to cause it to be twice as slow as ArcMap (I would think it should at least be equivalent if not faster)?

ThomasColson · ‎08-22-2018

I have a few examples of GP-Tool -> Python stuff working slower in Pro than in Arc that I'm not quite ready to share yet, however, might I suggest moving your PY question as new one to the Py section, where Dan Patterson will likely have an answer before you post it!

MichaelVolz · ‎08-22-2018

Are your GP Tool performance issues complex compared to just running the Geocode Addresses tool on a standalone table in my test case? I ask because I would be interested in testing your GP tool scenarios in my environment to see if I encounter the same issues.

Your idea to publish AGS services directly from Pro should be available with AGS 10.7 as per ESRI product manager. Would your org be able to upgrade to 10.7 quickly after it is released (a few months) or does this type of process take a considerable amount of time (6 months or greater)?