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

[JamalNUMAN]

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

[MatthewTokarski]

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.

[TylerSchwartz2]

Just to be clear, I support and like Pro, overall.  I think it has a lot of great innovations and personally I like the UI in general. 

My issues with Pro are purely on the development side - the bugs and the performance issues that are not being acknowledged or proactively caught and fixed by ESRI. The fact that its slower and less efficient than ArcMap in a variety of commonly executed tasks...  If they can get Pro to be as efficient as ArcMap and get the majority of the bugs (which they wont acknowledge are bugs) fixed, I will be 100% a fanboy of Pro. 

Please do not confuse my critique of the issues with the fact that overall, I see immense potential with Pro.  It just needs to perform better.

[ChristopherDean]

Attribute tables is one of the worst. If you scroll down or across the info/fields disappears so you can't tell how far you've gone. Then try a field calc or calc geometry. It's painful, half the time doesn't work. Then try to copy/paste in an attribute table, that crashes it every time. I've also noticed it seems to run fast overall on a new project but add a couple of maps, some data, use a project for a couple of weeks and it becomes unusable. Sadly I end up back using ArcMap for a lot of tasks. Hard to believe they push out such a bad product. I'm using 2.4. 

[MattWilkie1]

In my experience individual tools are generally much faster than ArcMap, but it takes longer to get to them and set them up to fire. In general, I find the act of using Pro to be sluggish and occassionally non-responsive for minutes at a time (20-30s is a common daily experience, while minutes is rarer but still happens every week).  From the responses here it's clear that there is a wide variety of performance experiences, and at opposing ends of the spectrum.

It would be really good if there were some downloadable toolset that we could all run and collect some quantified data that could be stuffed in a central table somewhere.

For example, I have an ArcMap python script  to measure data store performance on our premise. It opens canned maps that load data from a selection of sources (SDE, file-gdb, network share, ...) , exports each to pdf, and saves the times into a CSV. It's not readily shareable because of the dependency on our stucture but the idea is portable. Another lack is that the script is headless, which means it would miss the main part of my Pro frustration, the GUI. However this could be remedied with a self executing AutoHotKey script.

GitHub is an obvious and readily available place for "where to get the tool from" as well as "collection of testing recipes".  Care would need to be taken so that only shareable non-private info is collected of course. GitHub could also store the stats but there might be better choices for that.

In my opinion it would be better for the community to build this test suite than Esri. The tests would spring from our pain points not theirs, and the data public. It would be great-to-essential if they were active participants though.

Ok, so who would head this up? ...unfortunately not me. My development skills are middling and my time for next 6 weeks is fully booked. I can and will be an active contributor though, in spurts here and there. Ping me at matt.wilkie@gov.yk.ca.

[TylerSchwartz2]

This isnt our responsibility to collect data and test and quantify, its ESRI's. 

Thats why we pay for the software, and I am 100% sure they have the data and they are aware of the issues affecting slower-than-ArcMap performance.

[MattWilkie1]

I completely agree that's it should be Esri that is collecting, testing, quantifying and fixing performance issues. That we pay a lot of money for tools which should work and work well, to a professional level. However, they aren't doing that measuring and if we wait for them to decide to undertake that we'll be waiting a very, very long time. The fundamental problem is that Esri is a tool builder not a tool user. They do not see the problems or feel the pain because they aren't doing what we are. Therefore we need to communicate that in a way they can a) understand, b) action. A chorus of "this sucks!" might be momentarily cathartic, now we know wer're not alone and others are similarly unhappy too, but it doesn't incite change.

Matt

who has participated vocerifously in such threads many times since in 1995.

[YousreOdeh1]

I noticed I had the same issue in some of the process, some others were shown as complete, but when I check to output, I noticed the process has returned empty feature class, without any object. 

another issue I faced in ArcGIS Pro was when selecting features by their attributes, especially with time-series data, querying the dates using the query builder usual introduce "time Step" term in the code.  the solution was to switch it to the SQL and delete the "time Step".

The last issue is when editing features, filling the attribute through the editing session was not always reliable, in many incidents after filling up the attributes, I discovered they show up as NULL. 

That being said, I noticed there is an improvement in retrieving data in ArcGIS Pro compared with the desktop. 

Contour data for Delaware state was taking forever to get it loaded on ArcGIS desktop but it was easier on ArcGIS Pro. 

Also. Editing datasets from the server in ArcGIS Desktop, like that one for local government and utilities, at some point, used to take me the whole day trying to get it working, especially when it is about the time to perform post & compress process. 

[KoryKramer]

We've been watching this thread and wanted to respond to let you know that addressing performance issues is a very high priority for the ArcGIS Pro development team.  While comments are wide-ranging, the thread began with a post about the geoprocessing initial load time.  Much work has been done in this area for Pro 2.5 in terms of tool dialog opening speed, and we've also reduced overhead of disconnecting/reconnecting for layers in huge projects with many maps open.

One of the most common performance complaints we've heard, because everybody does this, is file browsing speed.  This was a large, multi-team project for Pro 2.5 and you will see dramatically improved browsing performance with the next update scheduled for January.

With some performance issues, the associated development team may already understand why something is slow and is already actively directing resources to address the issue, or has plans to address it soon.

For the transient/environment-specific problems mentioned, these are tougher since we may not know that they exist; i.e. we do not experience these in the extensive automated and manual testing that we conduct in-house.  Improvements in communicating specifics associated with these issues are essential to addressing performance issues that are not experienced in general by every Pro user.

We really do appreciate the open discussion and wanted to assure you that we take your feedback seriously.  Sharing specifics that demonstrate a performance issue or concern through a trackable channel such as Technical Support will be the most productive way for teams to take action on these.

If you are not already part of the ArcGIS Pro Early Adopter Community and would like to test a specific performance issue in Pro 2.5, please email me at kkramer@esri.com and we will send you an invite.

Thank you!

[MattWilkie1]

Thank you Kory. It is gratifying to know our concerns are being read, that these aren't plaintiful voices in the wilderness, unheard. This is a marked departure from years past.

A form or guideline for submitting performance issues might be a good idea. Though one of the drawbacks with submitting (solely) through a tech support channel is not knowing if one is alone in experiencing a thing.

[JamalNUMAN]

Hi Kory,

The post is never addressed exclusively to discuss the “toolbox” performance! It is related to the Pro performance in the wider picture. This is what has been originally said:

“I observed that the ArcPro has less performance than ArcMap. This observation is related to all tools and behaviors”

In addition to that, for me, my first front desk when it comes to reporting issues is the forum but not the technical support channel. Reporting issues to the technical support channel is one to one communication and not visible for the community. Sharing experience on the forum has countless benefits in all terms. In most cases, I got fantastic help in the forum for most issues I encounter in. Good community and willing to help!

However, I’m happy to hear that you guys are working in fixing all performance-related issues and some are already included in Pro 2.5! This is good news.

Best

Jamal