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.

[JoshWhite]

Using the right click option is seemingly instantaneous, I tried to time it but it is probably a second or less.  Unfortunately, when I tried the Add Join tool in ArcMap it gives me an error

The error doesn't make any sense (it's an Excel table, it has no OID) and also means I cannot fully replicate the process used in Pro. I know this ventures away from Pro but any thoughts as to why the error is coming up?  Perhaps this is similar to the issue Pro is having?  On the awesome side, ArcMap seems to have no issues with working with an Excel table.  I may just have to create this particular map in ArcMap for now.  

Don't you just love troubleshooting????

[PeterMacKenzie2]

I just did a calculate geometry (X and Y) field calculator on a 900 row attribute table and it took 15 minutes. WTF. Even if you ignore the whole local vs. network and processing, it's all the mini loading times that destroy productivity. Professional users don't need a fancy ribbon and big 'graphicy' contextual menus, they need a sharp clean, reactive GUI where things are locked into place so you can use muscle memory and keystrokes to fly through work.
The software should instantaneously load all of the frequently used windows like other have mentioned (i.e. symbology, select by location etc. No load time, just load. Look at Autodesk software for inspiration. Such a clean and productive interface. 
I do like the query builder for building definition queries ('includes the values...' drop down etc.).
ESRI should send a survey to Pro users getting them to rate all the aspects of the interface from 1-5. I'm pretty sure they would soon see what rocks and what sucks. 

[BillHegman]

Peter- We are teaching with 2.4 this semester and finding serious performance issues over our network.  So much so that we have students copy their data down to the local machine, do the work and then copy it back to the network for storage.  Even the littlest things, like creating a new feature class, fail across the network.  Connecting to a folder over the network is painfully slow.  OMG.  It almost seems like indexing is carried our every time I open the folder location.  The weird thing is, imagery from our server draws very fast and performs well.  

We're finding that doing operations off the local drive are reasonable.  Haven't see the long local processing times you mention, although we are just getting in to other functions and operations like joins.  We have brand new fast Dell workstations with Nvidia graphics processors and SSD drives, so maybe that makes a difference.  Still, our network uses a 27 TB SSD cache drive, so it should be just fine. 

This is almost a show stopper right now.  If we didn't have good local machines with large hard drives we would be sunk. 

Network performance appears to be a serious problem that ESRI is hopefully working on because it renders their software useless and erodes users trust.  Don't really know how this network performance issue escaped the developers and quality control folks at ESRI.  Baffling.  I've been working with ESRI software for over 30 years and this problem is in line with some of the worst performance problems I've seen.  

Bill

[ThomasColson]

You may want to call tech support and see if you're experiencing BUG-000118068 ArcGIS Pro projects stored in the My Documents folder hosted on a network file share with an offline feature service takes up to 20 minutes to open.

[BobSas]

Calculate field > enable undo, resulted in an order-of-magnitude increase in processing time on the same file, with an almost identical operation.  "Enable undo" turned on took 24 minutes to run... and 32 seconds with "enable undo" turned off. What can be done so that "enable undo" becomes a usable option that isn't so expensive for efficiency?

[KoryKramer]

Hmm, I just had the opposite experience.

Calculating a field with Enable Undo on completed in 6 seconds:

With Enable Undo off it took 15 seconds:

I can play with this some more, but more details may be needed...

[KoryKramer]

Bob, are you working in a project with a number of maps/layouts?  

If you were to open an Untitled Pro project and work with the same dataset, what do your performance numbers look like?

While it is expected for processing to take longer with Enable Undo on: Undo geoprocessing tools—ArcGIS Pro | ArcGIS Desktop 

Performance and scalability

When geoprocessing tools are run in an edit session, performance will decrease compared to when the same tool is run outside an edit session. Similarly, scalability will decrease, as fewer features can be processed in an edit session compared to outside an edit session.

the example you're giving of 32 minutes doesn't seem right.  

I just did another test

ArcGIS Pro 2.4.2

49,542 points in shapefile.

Calculating Long field.

Enable Undo on = 1 min 14 seconds

Enable Undo off = 47.45 seconds

Are you able to provide a project package that we could use to investigate the performance you're seeing?

[BobSas]

Yes, the issue seems to occur with too many maps/layouts open in the same project. 

[KoryKramer]

Thanks, Bob Sas‌  At this point, we can assume and hope that the work already done in ArcGIS Pro 2.5 will resolve the issue you included in the comment above.  If you are able to share the project package, I can get it to the appropriate team as a real-world test case which can either validate the development work done, and/or may reveal areas for further optimization.  Thank you!

[KoryKramer]

Hi Bob Sas‌ Would you be able to share the project package where you're seeing the long lag shown in the screenshot?  We believe that what you're showing will be improved in ArcGIS Pro 2.5 with better handling of projects that contain multiple maps/layouts, but we can't be sure unless with test the case you're showing.

If possible, and if the package is small enough to email, could you send to kkramer@esri.com?  If it is too large to email, send me a message and I can set up a file transfer site.  Thank you!