Make ArcGIS Pro Performance Just Decent

[DarrylAlbert]

I think it would be great if the performance of ArcGIS Desktop 10.x could be matched, at even 50%.  Much of the great ideas and efficiency concepts built into the new software are zeroed out by basic performance problems.  For example, it just took 2 minutes to cut a 5 acre polygon in half.  The spinning blue wheel is our best friend here in our company.  It gives us lots of time during the day to refill coffee, go for a walk, etc. 

All sarcasm aside, it's a major problem.  We have teams of IT staff testing and monitoring users and traffic to troubleshoot these issues for dozens, if not hundreds, of users across our company.  It appears we do not have enough degrees and people available to get ArcGIS Pro to work satisfactorily.  It shouldn't be this difficult and it didn't use to be.

Software licensing costs with ESRI continue to skyrocket while software performance tanks. 

[HbAGeoinfo]

We are still using Catalog/Arcmap next to Pro and there's always a notable difference in the time it takes to complete a certain task.

Deleting a fc from a gdb for instance usually takes 3 to 4 times as long in Pro. Starting Pro. Just previewing fc's in the catalog view in Pro is so much slower than browsing through them in the original Catalog. For every simple task Pro first has to start a tool which adds to the time it takes

I'm sure if I put some more thought in it I could come up with dozens of examples. It would be great if Pro would solve this in the future but my bleak opinion is that once people only work with Pro we'll  forget that it used to work faster and we will all happiliy stare at the blue wheel.

[LindaGreen]

I know this is just a drop in the bucket of slowness people are experiencing, and it doesn't holistically address the issues you're having, but the animated effects in Pro seem to be a persistent source of slowness for me (especially with splitting features), and it's possible to turn those off in 3.5. 

https://community.esri.com/t5/arcgis-pro-ideas/turn-off-animated-effects-in-arcgis-pro/idc-p/929386

[AlexMontalvo_IER]

Thank you @DarrylAlbert. The performance in our organization is so poor we are going to start testing QGIS for production work. Simple geoprocess tools take far too long to process. When you add up these performance delays over the course of day and then a week it has a large impact on our ability to deliver projects on time and on budget. 

[RTPL_AU]

You may say I am frustrated this morning.  Pro has just crashed for the third time in less than an hour.

A geology map I made in ArcMap on a much slower computer seems too much for Pro 3.6 to handle on a MUCH FASTER machine. 
State geology maps with pre-cooked styles and their legends are never fun to use but Pro makes it a terrible experience. 
I know there are many ways to skin the cat and remake symbols and legends to suit the project areas but why should I have to?

[RTPL_AU]

@AlexMontalvo_IER 
I use QGIS quite a lot.  
For data viewing and import/process of non-Esri formats it's fantastic. The plugin diversity is both a benefit and drawback - plugins can disappear/go unsupported, or get commercialised (good for support, bad for budgets). 

The lack of a cost competitive and functional equivalent ArcGIS Online + FieldMaps integration is an issue. Very good options exist but what you save in $ (if at all) is offset in time spent when your state/council/clients all use ArcGIS.   

I find it telling that Esri/Pro generated data such as tile packages, map services, etc can be faster in QGIS than Pro - at the same time, from the same source, on the same machine. 

Packaging data, styles, and maps/configs in a single geopackage is something Pro really lacks; and the inability of Pro to leverage geopackage capability has to be a conscious decision. 

QGIS + PostgreSQL is a great combo.  A client uses an Azure PostgreSQL instance to share data with stakeholders and the performance to a local QGIS instance is SO MUCH better than Pro + AGOL (not quite the same thing but equivalent).   On the flip-side, cooking your own security and identity management for publicly hosted open source options is not something I want to get into. Yes - there are commercial options but they are often similar or higher cost than AGOL with less functionality. They have bugs too.

[Miralem_Zeljo]

Darryl, you are certainly not alone. We have also been unable to share packages for reasons that remain unclear. Although the previous revision allowed us to get it working through a geoprocessing tool, the latest revision has introduced new issues — even when using the current version and the same geoprocessing approach.

I sincerely hope Esri treats this with the seriousness it deserves and strengthens its debugging processes. Early Adopter participation is a step in the right direction, but realistically, most leading software development companies invest heavily in thorough, systematic debugging to prevent situations like this.

@ESRI Quality Control Team