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.

[ThomasColson]

To be blunt and to the point, the only way it's going to get addressed is via tech support. I have at least 2, and more in the pipeline, cases just on performance. SDE performance. Blowing up my CPU cooling fans. Some GP processes take twice as long as AM. The so-called "recommended" hardware in fact is "barely start Pro" specs. Here's how this works: I have an SDE case, and they find that the Transmorgifier, only present in a few customer environments, is generating excessive SQL queries to the bunny rabbit. You open your SDE case, and they find that the Supercalifragilisticexpialidocious Equalizer is spinning in the wrong direction if you installed Pro on the 3rd Wednesday of an odd month while it's raining and you forgot your lunch. You share this on GN, and I discover that my Supercalifragilisticexpialidocious Equalizer  doesn't spin at all. These are things that no QA Test Plan will ever discover, and no intern in the test lab is ever going to think of. So, instead of one customer pissing and moaning to TS about SDE (me), there's now 2, or 4, and they have enough SDE Intercepts and Traces to actually change some code. But, don't be discouraged about sharing your experience on GN. I probably solve half my problems on GN based on ya'll's input, which keeps the TS lines open.....

[AlexZhuk]

I posted it already somewhere before - a major redesign of Pro is needed. But it's $$$$$$$$$$.

[SeanHlousek]

Loved your explanation.

I'm of the same mind with Tyler.  I'm frustrated because even though we've all paid for completed software I think we are experiencing incomplete and extremely buggy software.  

UI testing and QA/QC needs to be on the developers time and money, not the Users.  

It says something when I'm taking time to learn an entirely new (to me) open-source GIS system because time-wise I'm getting a similar ROI to what is supposed to be the new flagship product for the GIS system I've used for 17 years.

(FWIW - I've already spent a LOT of time on Tech support calls too.  I'm hoping that all of that time will help them make improvements.  However, it's disheartening when they still haven't fixed basic performance issues like table editing in 2.2).

[TylerSchwartz2]

Thomas you bring up a good point that there are some things, so specialized, that no QA/QC team will discover, and I accept that.  

[MichaelVolz]

I think that ESRI should incorporate SDE data from multiple types of databases (SQL Server and Oracle) into the Pro training classes (currently they use file gdbs), so the trainers can see first hand some of the slowness issues that Pro clients are experiencing with these more complex datasources.  I think then internal ESRI people might help to persuade ESRI management to focus more effort on improving the base product instead of focusing on bells and whistles for tools in Pro that only very specialized GIS people use.

[BrianE]

My company has the same issues. EVERYTHING runs slower when on a network. I do  not understand how, in this day and age, this is a problem and why it is not being addressed immediately. We have been working on a network slowdown issue for a year with Esri to no avail.

1.4 works fine but when we upgraded to 2.X everything dragged.

[CyrusBlankinship1]

Couldn't agree w/ briertel more. Why have read/write speeds slowed down with the 2.x version of Pro?? It has made the product completely unusable since our team continuously shares projects w/ each other over our server and are accessing 5+ gb of data. 

[ThomasColson]

Changing symbology of a SDE point feature class in Pro 2.2: 

Note how long it takes. Looking at wireshark logs while this is occurring, an incredible amount of traffic is going back and forth to SDE. Why? Because in Arc Map, I can change the symbology 5 times in the same amount of time it takes to change symbology in Pro. And guess how much back and forth is occurring with SDE when I do this in Arc....not much...

Performance gets even worse when you turn off caching for a map layer, which was the solution to BUG-000113527 ArcGIS Pro Attribute pane fails to dynamically update data for values calculated through SQL for published feature services. 

The result of the bug that I logged on this in 2.1 is "Implemented in 2.2", so I'm hopeful that others in the community are experiencing this same specific issue: "Changing symbology in Pro takes 2-10 times longer in Pro than the same exact SDE data source does in Arc" and can get some attention on this issue that, judging from the other posts in this thread, probably affects a very large number of enterprise customers. I plan to reopen the case, but expect a "cannot reproduce" outcome......

[DanPatterson_Retired]

Thomas... so the issue seems to be with how SDE and Pro interacts.. 

ArcMap, you suggest, behaves nicely with SDE?? all the time? 

Do you have issues with locally stored data? 

I am trying to get my head around who is the 'villain' in all this

[ThomasColson]

In terms of data access, locally stored always is faster, in Arc and in Pro. However, with locally, there are other Pro performance issues. I just used what I think are one of your Py decorator examples to time stamp some common GP tasks. Everyone of them is slower in Pro/Pro Py. Neither behave nicely with SDE all of the time, IMHO, it's just Arc Map "chatters" less with SDE than Pro does. That much is evident from numerous traces, profilers, and perfmon counters. Back in the good old "T1 Line" Days, you couldn't even connect to a remote SDE with any ESRI product. So a lot of this is function of your WAN speed, but, like I exemplified above, even on the same LAN connection (a 7 MB VPN today), Arc outperforms Pro.