ArcGIS Pro: 2.4.2: In general, ArcPro has less performance than ArcMap,
I observed that the ArcPro has less performance than ArcMap. This observation is related to all tools and behaviors
An explanation I received from this recently is because unlike ArcMap, where the license is stored on a local server, ArcGIS Pro uses your Enterprise/AGO log in to reference the license. Therefore ArcGIS Pro is constantly pinging your Enterprise/AGO for authentication and licensing, which causes a delay in some tools. From what I was told, it is something ESRI is working on correcting. I'm sure there is more to it than this, but this is an explanation I received from an ESRI rep a few weeks ago while on site at our office.
I'd certainly like to be challenging the rep on that!
Previously I've borrowed a license, completely cut off any internet connection and still it is lagging behind on the simplest of processes.
To confirm, you did this? Just unplugging from the internet isn't the same
Thanks Dan, ArcGIS Administrator calls it borrowing, so still using that wording to describe the task.
But yes, that's what I did otherwise I wouldn't have been able to use ArcGIS Pro as it would be asking to terminate the program without a license.
Dan, I run Python Toolboxes, calling Python scripts, and they are large. Some have 6K lines of code (with a lot of whitespace and comments.) Multiple subscripts are called. It takes 10-20 minutes for my larger Toolbox to Refresh in Pro 2.4.2.
Using the IDE by itself and calling a clone, using Pro commands, it is able to check syntax, do a test import, and run the entire suite of geoproccessing tasks in that same period of time.
This is with "Authorize ArcGIS Pro to work offline" active. I have a stand-alone license. Scripts are on the network. Data is on the local machine SSD C-drive.
I already clear the cache frequently, and do not cache data that is frequently updated. If there is a configuration change that can speed this up, I'm all ears.
Kevin, I probably can't help since I store and use everything on a local machine.
I prefer custom toolboxes since I can document the parameters and validation code using screen grabs (png graphics) but I doubt that the type of toolbox would have an issue. My scripts all have a testing/toolbox call so I don't even need to open Pro for the mostpart.
I have never seen that kind of slowness. Most of my work is geometry or raster related. No mapping stuff, no symbology, none of that,
When I work with tabular data, it is purely through numpy, (reclassification, ranking, field calculations, data validation and joins) and bring the 'stuff' back into Pro should I need 'see' a map of the results.
For me nothing seems slow but I suspect that it is what I work with and work on that differ
That's not entirely correct - at least not the licensing part. ArcGIS Pro can be licensed in 3 different ways:
We use Concurrent Licences (the same way as for ArcMap) and although I appreciate that Pro would check licence availability/LM connection from time to time (as ArcMap does the same), it should not be a detriment to performance - especially not on a way that launching a tool from toolbox would take minutes to do so...
Try scrolling through an attribute table and see how laggy and unresponsive it is. There is a plethora of performance issues that Pro suffers from, but just scrolling through an attribute table is the most stark and easy to see. Beyond just the performance issues, many other problems exist (signing in/out of accounts doesn't update Pro/AGO permissions/extensions, catalog file tree doesnt update/forced refresh needed, the list goes on).
Here we are over two years out of beta and we still have beta level issues persisting and not being patched or caught by development/qaqc team. I was an early adopter, and because of that I have seen all the bugs and issues present from version 1.0 til now - many have been fixed (some of which I had to report)... whereas other, larger issues have not.
Selecting polygons, performing edits, running a calculate field, ribbon/UI updates, spinning wheels. These processes should have instantaneous responsiveness like they do in ArcMap, but they dont. These are the issues that users are complaining about, and they are not small issues!. This inefficiencies in Pro add up over the course of a day and causes frustration when the software cant move as fast as your mind.
This is accentuated because ArcMap DOES move that fast, so these issues are amplified. The feedback specific to Pro being less efficient than ArcMap on Geonet is widespread-- I do not accept that these are isolated issues and I believe ESRI knows about them but arent being forthcoming about it.
I will freely admit I LIKE Pro and it DOES have a lot of great things going for it. . I like the UI, I like the new map layout/legend, I like the added symbology and labelling options (transparency), but all of those things fall flat if it is much less efficient than ArcMap. We expect Pro to be as responsive (or more responsive) than ArcMap and we expect ESRI to QA/QC their product, not us.
ESRI needs to get serious about the speed and efficiency issues that Pro currently has if they expect users to adopt Pro over the currently much more efficient ArcMap. Surely ESRI knows this but cant seem to achieve (or acknowledge) it, why?
I feel your frustration frothing from the post as I read. This gets so ridiculous I just give up entirely on Pro and won't use it for a long time. Then, when I come back to it, I am reminded and disappointed once more of its deficiencies. Where's Mr. Dangermond in all of this? Does he realize what is going on?
The issue is not licensing. I'm not yet at TS levels on this yet, but if you turn on SDE Intercept and Fiddler, the amount of network traffic generated by Pro compared to ArcMap is on the order 50-100 times more. Even with the license offline. Even had a case that was borderline reproducible confirm the latency, but "borderline" cases never go to development. Stay tuned, my next case on this topic will be reproducible, so help me sasquatch.