ArcGIS Pro: 2.4.2: In general, ArcPro has less performance than ArcMap,

25214
122
10-27-2019 11:42 PM
JamalNUMAN
Esteemed Contributor

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

----------------------------------------
Jamal Numan
Geomolg Geoportal for Spatial Information
Ramallah, West Bank, Palestine
122 Replies
MatAzzopardi
New Contributor III

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.

DanPatterson_Retired
MVP Esteemed Contributor

To confirm, you did this?  Just unplugging from the internet isn't the same

MatAzzopardi
New Contributor III

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.

Kevin_LeeHayes1
New Contributor

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.  

DanPatterson_Retired
MVP Esteemed Contributor

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

zkovacs
Occasional Contributor III

That's not entirely correct - at least not the licensing part. ArcGIS Pro can be licensed in 3 different ways:

  • Named User (default) via AGOL or Portal
  • Concurrent Use
  • Single Use

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...

TylerSchwartz2
Occasional Contributor II

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?

RickGonzalez
New Contributor III

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?

ThomasColson
MVP Frequent Contributor

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. 

MatthewTokarski
New Contributor II

I'd love to see your data on this because I'm having a very hard time convincing my IT department to upgrade the ancient 100 Mbps NIC cards in my department.