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.

[diaconori]

nobody dares to say it, but it is because they have built it in a way that every single click on the GUI checks for a valid license. Every **bleep** click, so it is super freaking slow. Makes you want to build a competitor really lol... Multi threadded, async and c++, and it is still a lot slower than arc map LOL

[jcarlson]

Am I the only person with the inverse of this problem? I have never had ArcMap come even close to approaching Pro in terms of speed in any the workflows I use on a day-to-day basis.

[KoryKramer]

No, Josh, you're not the only one!  But for some who do try to compare ArcGIS Pro to ArcMap on the same machine, it will be important to ensure that the machine meets or exceeds Pro's system requirements as they are different from ArcMap's.  Troubleshooting Performance Issues in ArcGIS Pro has some important first checks to run, including the ProPAT benchmarking tests, as well as sections to investigate more specific areas like mapping, geoprocessing, etc.

[diaconori]

We are an entire organisation that runs lenovo's latest thinkpad series, computers with hardware that cost roughly $2000+ for the consumers. It is not an issue related to hardware. Every user here has a fiber connection with minimum of 1 gigabit speed, so it is not network related either. Must be the clunky code and tons of mass license validation because arc map does not include these problems - we are currently migrating all our projects to arcgis pro, so it is very frustrating to experience these issues.

[RTPL_AU]

Edit:
This seems to have been fixed in a recent update (as at 3.1.2). I missed it in the Release Notes so what else was changed without telling us?


A good example of  deteriorating efficiency and productivity below.
When you open the Calculate Field tool during an existing edit session the data/equation edit field is hidden due to chosen default window size and messages that could be better placed.

No user will ever open this tool and not use the Data field. Did it not occur to the UI designer and UX tester that the layout and this behaviour is an issue and wasteful?  
On its own it is just a mouse scroll away but when you add all these little things that eat up clicks and scrolls it adds up to significant time wasted by the user base.

I tried to lodge it as a bug with Esri Australia but "Unfortunately, feedback from Esri Inc has stated that the current UI traits you have pointed out are not warranted enough for a bug creation".

If this isn't a bug then it is designed to be what it is? 

[LaurenWinkler]

I agree, @RTPL_AU, this is poor UX design that wastes time. Of course, the calculations are also significantly slower, so I think this should absolutely warrant bug creation. Please log this as its own idea so it doesn't get lost.

[RTPL_AU]

Hi Lauren,
Re Idea:

The issue is so wide-spread that the idea would read "Hire appropriately qualified UI designers and UX testers". I don't know which Idea Exchange (?!!!) to place it in 🙂

Re Bug:

Been there, tried that for many.  Feedback about this one from Esri Inc in my post above. For another lodged case about issues with mouse click recognition I was told "work slower"..

[KoryKramer]

See https://community.esri.com/t5/arcgis-pro-ideas/make-the-calculate-field-gui-bigger-longer-by/idi-p/1... 

[RTPL_AU]

Thanks for that Kory. There should be an enhancement request from Esri Australia in the mix at Esri Inc as well.

I do find that thread a bit concerning. Have you read it through?

Why are Esri staff asking users UI design questions without mentioning/using an objective UX validation process? By Esri: "Thanks for your comment.  So, I guess you wish........". Seriously?
The fact that the thread exists and the current outcome seems to require user interaction to fix the issue temporarily demonstrates that there is a lack of skill and understanding regarding UI & UX in the Pro dev team. 

Think about it:

Current Problem = Due to status messages (unnecessary?) Tool window is too small to get directly to the primary interaction space. 
Current ArcMap Equivalent = Move to and Click in primary interaction space - no issue. (see note below)
Current solution = Move mouse and scroll. Move to and Click in interaction space.

New Proposed Solution = Move mouse. Click and Drag to required size. Move to and Click in interaction space. Application will retain user preferences.
Seems good doesn't it?  Single task equivalent performance is down the drain!

Take a step back and look at it at a higher level. Looking at Pro as a whole how often do saved UI layout changes bomb out? 
Every now & then a window will show up in a completely random location after being closed.

Further to this how will this process work when you have two Pro sessions open and changes are made in one only. Does the sequence in which you open & close the sessions matter as they do in ArcMap?
Where will the settings be saved? In the AGOL/Portal user account or on the local machine? I use multiple devices and keeping all the settings to make it more productive in sync is a pain. 

Wouldn't you agree that optimising the layout of the window to remove any required user interaction to be a better solution?  

If Esri is serious about this maybe there should be a specific Bugs Exchange for UI & UX. 
(This is a bug and to call fixing it an idea is insulting to paying customers)
Bring a qualified UI designer and UX tester into that exchange and have them interact with users in a structured way while compiling sensible metrics and processes for the application design team AS WELL AS creating improved training material for users -> if platform limitations prevent efficient and intuitive design you have to educate.

Notes - to provide further context 

ArcMap Note:
The Pro toolset/dialog is much more powerful than in ArcMap but, for most users, most of the time the ArcMap window is fine and efficient.  

Allow resize & save window Note:
This has memory and processing implications. Having a resizable window can be a good thing and retaining the settings more so. 
In my view this is an enhancement that needs to be evaluated in complimentary context to the size issue as it has a non-trivial system and architecture impact.  This thread is about Pro performance and the noted proposed solution to the window size issue is pitting UI/UX changes against system resources. 

This stuff is complicated! 

[RTPL_AU]

I posted this as an Idea today but it gets back to feature parity and the original question of "Why does ArcGIS Pro have to be so slow???" while having nothing to do with data complexity or hardware spec in and of itself.

Pro no longer has the 'browse to default folder or database' buttons in any file dialog window.

If you have a complex project it takes multiple clicks and potential scrolls to get to your default database or folder where it used to be 1 click in ArcMap, no matter where you browsed to before.
So, yes, data or project complexity does intersect the issue but only means the time & effort saved will increase the more complex the project or the slower your network.

Another small example of the lack of understanding of efficiency by the design team.
You lose nothing by adding the two buttons back but it will save your users time.