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
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.
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.
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 firstname.lastname@example.org.
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.
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.
who has participated vocerifously in such threads many times since in 1995.
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.
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 email@example.com and we will send you an invite.
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.
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.
Thanks Matt Wilkie and Jamal NUMAN. I totally get it, what you both (and others on this thread) say makes sense about putting something like this out to the community. From an "actionability" standpoint, a thread like this is a good signal that there is work to be done on performance in Pro. But without specific steps and comparisons, dev teams may not know there is an issue specific for their team to address.
Matt, to get at your question of what to include when working with support, system information is a great start. An easy way to get that is to run 'Check your computer's ability to run ArcGIS Pro 2.4' from ArcGIS Pro 2.4 system requirements—ArcGIS Pro | Documentation Take a screenshot of the results and save for later. This is a quick and easy way to rule out anything obvious.
For performance issues, users are often comparing something to something else - in this case, Pro is slower than ArcMap. OK, not for everything, so for what? Make a note of the data type (file gdb, shapefile, enterprise gdb (what rdbms and version?; using versioning (branch, traditional?), etc.), where the data is stored - local, network share, where are the servers, and some details about the data - is it 5 polygons or is it 500,000 points that participate in relationship classes, or topology, or... I understand that when comparing ArcGIS Pro to ArcMap, these are constants. It is the same data, in the same location, and ArcMap is faster than Pro. Perfect, but what often is missing are steps and times. Once we have that, now there is something that is more actionable.
So after laying out system specs, and details about the data, a performance case would look something like:
Completes in 3 seconds.
Completes in 15 seconds.
Detailing the above will usually help us understand which team is best equipped to analyze the issue.