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
Kory,
This is how you can help all of us suffering ArcGIS Pro performance issues:
Smooze and convince the software development leadership to hire beta testing companies to test every version of software - every time - no exceptions.
I know, it's a risky and potentially career ending mission. The fate of our future loyalty to ESRI depends on it. No pressure. Here's what I know:
It's clear that ESRI doesn't do professional beta testing. If they do, it's token and not being done by a real beta-testing firm. A competent beta testing firm's mission is to break a client's application and report how they broke it and provide recommendations for bug fixes on every aspect of the software. Circumstantial evidence suggests ESRI thinks it doesn't need this expense when it has a majority of clients as captive customers. Why contract out professional beta testing firm when ESRI can use their customers? I get it Kory, there's no major financial incentive for ESRI to improve its software development process. I understand you do not have power over the ESRI development team for ArcGIS Pro. Your job is PR - not technical support - and you do it very well!
So, let's get real honest here. We are all wondering this: How can the most popular GIS software firm NOT improve their software development process like every other software development firm over the past decade? Complacency? I know ESRI is angling to become an AEC firm. Maybe ESRI's long-term goal is not commercial software development. This would explain why we see no prompt attention to these major software performance issues because it's not their priority. Nevertheless, perhaps I should follow Occam's Razor and simply recognize that ESRI just has a poorly managed software development team with no motivation for alpha QA because of their nearly captive customer base.
However, when the small firms start going elsewhere for their GIS software en masse and starting winning more work than the major AEC firms, the major AEC firms are going to notice. In fact, I'll let you in on a little secret; it's already happening. I think you know how this trend ends. I guess the later thought provides more circumstantial evidence that ESRI is moving their focus away from their commercial software. I work at a major AEC firm, so like many of my fellow end-users on this forum, we will be slow to adopt to other GIS software and/or methods of working GIS - yet we will be beginning to use non-ESRI software. This isn't a threat. This is a promise in a production driven industry. The truth hurts, yet it does set one free.
How about your experience in 2.7.2?
Also missing in Pro is the home and default gdb options on the export window (for both data and pdfs):
Here's another important feature missing from ArcGIS Pro that's in ArcMap. Please give it an up-vote.
ArcGIS Pro: Enable "Add all values" to use format settings from "All Other Values"
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.
I have noticed significant delays in general navigation through the application. Which gets especially bad if you are faster than the application itself.
Examples:
Just want to give kudos to Kory Kramer and the Esri folks who spent time with me today walking through some of the issues - we do have some very caring folks behind the scenes that do want this to be on the continuous improvement scale in the up direction and for one, I will say again,
I truly appreciate the great support that we get from you guys and gals in the various development teams and in the Support Group at Esri. When there's trouble, there is support to help.
We really do want Pro to work and realize that it takes time to get there - and including us in the process makes us feel better, for sure!
Thanks for more info to consider - yes, we've all done some hoops for our ArcGIS installs - always good for a conversation opener with the IT packaging teams I've worked with - "Hey, want some fun challenges to solve?" - It definitely encourages creativity - especially when they know that management wants this package out there and there is no "no" option.
ArcGIS, however, is not alone in challenging enterprise IT departments - some of the heavy-duty geoscience software out there that has a high pricetag definitely pushes the envelope - one popular one even drove the build of a new data room in an old building in London where one of our teams was located as well as having to get a different configuration of servers because the doors were too small for some of the equipment (this was all pre-cloud) - very many challenges... connectivity being another - internet in some places simply is not accessible except through something like phone lines and a Hayes modem! One lady from Alaska was lamenting that they could not use AGOL due to this. It just would not work with the bandwidth limitations and areas where they had NO connectivity - deja vu back to the early 1980's!
Thanks for responding to my post!
I see "crashing" as less of a barrier to IT support, but the rapidly increasing hardware requirements with each version have definitely been proven to be a significant IT barrier.
Ellen Nodwell wrote:If something crashes a machine in testing, for instance, this would not be allowed for an organization-wide push until that gets sorted out. That's a reality experienced in organizations whose IT governance has tight restrictions about software that is run on its computers.
Ellen Nodwell wrote:
If something crashes a machine in testing, for instance, this would not be allowed for an organization-wide push until that gets sorted out. That's a reality experienced in organizations whose IT governance has tight restrictions about software that is run on its computers.
I just wanted to highlight this point as a major concern. For some, this is a deal breaker. Luckily we have a very amenable and helpful IT group but we are constantly stepping on their toes all the time with Esri's requirements. I figure we give them more headaches than the rest of the organisation combined.
For example in order for an allied client to edit our GSB at 10.3 they had to punch through the external firewall (ICT haaaate it) and to do DB maintenance the admin user necessarily has to have root access over the entire oracle database, which ICT instantly vetoed as 'yeah, that's not happening'. So we have to use some dodgy unix scripting on the server instead of simply 'right-click compress geodatabase'
Just some examples of how Esri software design doesn't play well with enterprise-level structures. These best-practise (and sometime mandatory) security principles should be anticipated for and incorporated into ArcGIS development.
PS: We've got Pro to crash a few times (mostly around map export I think) but never take out the OS.
Based on the last available news 2.3 was at ArcGIS Pro 2.3 Beta so I'm going to guess ArcGIS Pro 2.5 Beta but it doesn't work (or at least, yet)
You can also find prerelease versions over at Misery if your account has the appropriate permissions for your organisation. (Pro Beta is not there either, yet)
how I can try ArcGIS pro 2.5 beta , from where I should install?
"The big frustration is that we have to document every feature that was already there in ArcMap just to get the fabled ArcMap equivalency. I wonder if ESRI could/has assigned a team to comb through all of ArcMap's menus, forms, tools, etc. in order to verify that every feature in ArcMap has equivalent functionality in ArcGIS Pro, and that if a feature has been left out, to document why it has been left out. Has this occurred?" Yes, the customers are that team.......
True that, it is a frustration. Like having a house custom-built, only to have to tear down the walls (yourself) because the developer said "Well you didn't specifically put in writing that the house needed plumbing or wiring, but check out the pool we installed that you didn't ask for!". And all the doors in this house are stuck in their frames and you have to kick them open and the windows open really slow.....
Thank you for the thoughtful, balanced account of your experience using ArcGIS Pro, Ellen Nodwell.
In the spirit of trying to help, I wanted to pick out two of the more specific issues you wrote about.
1. Trying to do 3D analysis and you get an error 999999. Did you try the steps listed in the error help 999999: Something unexpected caused the tool to fail. Contact Esri Technical Support (http://esriurl.com/support) to Rep… ? and still get the 999999? Even so, the geoprocessing team is always trying to eradicate these unhandled exceptions, so they need specifics that lead to them. From what I can tell, a bug was not reported for this particular 999999.
2. Regarding the crash, did you submit the error report along with your email address? I don't see anything recent. While development teams have both automated and manual tests in place, and there are numerous holistic testing sessions that take place before software is released, not every possible scenario is caught. Submitting error reports after a crash, including an email address and as much description as possible makes it much more likely that teams will be able to understand, isolate, and fix an issue. More on the process here: ArcGIS Desktop Error Reporter Learns Its Manners
Wow! Thanks for all of that research and the time you spent documenting this.
I know you probably have a long list, but every time you have an "ArcMap equivalency" issue, please create an Idea or a Question here on GeoNet and put the words "ArcMap equivalency" in the Tags section of your post.
I, too, began with ESRI in the "good old days". I began at ArcINFO 7.X and ArcView 1.0 to 3.X. My first exposure to ArcGIS Desktop came at 8.2, which started at 8. I remember my first impressions of ArcGIS 8.2 were that I liked it right away. It was immediately the equal of ArcView 3 in basic functionality. I do remember some challenges learning to burrow down through all of ArcMap's forms for labelling and other things. It did take time for ESRI to add all of the geoprocessing tools, but ESRI was very clear on that and gave periodic updates to let everyone know where they were at with what we would now call "ArcINFO equivalency". NOT that ArcMap has been a bed of roses, unless you count the thorns. Don't get me started on bugs! But as I've heard Jack comment at the conference, ArcGIS is the largest software implementation on the Microsoft platform IN THE WORLD. So, bugs just go with the territory.
I think that ESRI's big challenge here is that the ArcMap user interface is soooooooooo much more complicated and sophisticated than what came before it. A LOT of fine tuning has gone into it over nearly two decades and it works pretty well. Every check-box and input parameter has a user who asked for that and users who depend on it. So, much thought has gone into ArcMap over the years that has not yet occurred to the ArcGIS Pro developers. So, stuff has been left out.
The big frustration is that we have to document every feature that was already there in ArcMap just to get the fabled ArcMap equivalency. I wonder if ESRI could/has assigned a team to comb through all of ArcMap's menus, forms, tools, etc. in order to verify that every feature in ArcMap has equivalent functionality in ArcGIS Pro, and that if a feature has been left out, to document why it has been left out. Has this occurred?
Reply to original discussion - at this point - this has many threads and offshoots - so, that's difficult. However, I am going to jump in here...
I am a fairly picky very experienced ArcGIS user - I have used every version of ArcGIS since the days when we first had a PC application called ArcView introduced to us... Yeah. I'm old.
So, IMHO, ArcGIS Pro in it's current "production" iteration has been presented to the users as "you'll love it - like a duck takes to water"... yada yada yada. Well, no, it isn't so hard to learn to use it, but does it work as well as ArcMap? No.
OK. Reality:
OK, so, what do I mean by "I'm not. Still." ?
#1 - it is slow(er) - or should I say, it's very BOGGY - it seems to be very busy doing lots of things that make my machine make noises and sound like it's nearly stressed out - I watch the performance meter - hard to pin down exactly what is sucking the resources the most - sometimes it's nothing really - it just seems to be doing "something" (?) and it's not wanting to be available to me at that time.
I wait on it. A lot. I wait on it to do some things that should be relatively quick. I know that each layer has some hooks to stuff and that we need to minimize to only what we need. Basic managing resources 101. But sometimes, it's the basemap. Sometimes it's just ? something only ArcGIS Pro thinks should take a long time. Who knows?
Sometimes it comes back and is perfectly happy and goes on normally enabling me to do all kinds of things - as long as the data doesn't get too big for it - don't even think about doing any sort of large scale crunching! No way. I have a biggish data set that I can't even load into Pro without it croaking.
This is all inside my environment - no network shares - no remote databases - this is all inside my very hefty environment on a gaming-quality high-performance machine. It's me and my connection to ArcGIS Online - which may be one of my issues, I suspect... but sometimes, when totally disconnected (and I have tried this), Pro just won't do things without getting fussy. You tell me.
Geo-processing? Oh. my. goodness. I did attempt a few routines here recently and the outcomes have been horrid (this is on an attempted view shed plain vanilla analysis) - first time, it totally crashed my machine! Seriously. Big time core dump. Assassinated everything and I had to do a hard shut-down the power type restart. Prayed I wouldn't get the "blue screen" = yeah - that bad.
The next time, I reduced my AOI - tried it again. Got one of those 9999999xxxx errors - meaning - "Yay! Congratulations! You win the "bug-finder" prize!" essentially - or else there isn't any exception handling for your exception (you exceptional thing, you!).
Well, well - this is not new. I find bugs a lot. It's not my favorite thing. I get good and frustrated - but, hey? What am I going to do? I need to get my work done.
I need to do the analysis that crashed my machine. I don't have time to now go off and create some alternative script because this out-of-the-box tool does not work. This means that I have to take extra time and I have to go to extremes and be clever to figure out some sort of workaround - all because I "happened upon" a part of this software that doesn't work.
Options? Call Esri Support. Do that thing. They do try their best. Good folks. But sometimes these problems that we have with Pro, these stress them to the max. You can hear it in their voices. I try to not get frustrated with them because they are trying and they are on your side.
Occasionally, there is an answer, sometimes it goes on a list...and of course, this takes time for someone to figure out and/or find someone to help figure it out if they can't figure it out... and this could take some time. More time that we have.
Ticking clocks. Work not getting done. That's the point - we're not out here using ArcGIS Pro or Desktop to have a holiday. It's for work product.
So, yes, I sound frustrated. I am. I want to run a 3D analysis and it keeps crashing! I just want to get my work done!
I just want this to work and I want it to work BETTER than ArcMap. ArcMap has evolved after a serious number of years whereby users asked for fixes and new functions to be better and better. ArcGIS Pro is a great idea. I think that we are on a curve where we are still watching it evolve and going through that "stuff got left out or stuff isn't well tested" or potentially, the data used for testing isn't what we out here in the trenches are facing each day in our work - we really don't know all the reasons why we are not seeing vast improvements each time. But, each time we do see some improvements. We just want the product and what's inside to work - or else, if there are limits - state them.
Since you can do an analysis of your machine's capabilities to run Pro, why not have something that spells out your limitations when you go to run a geoprocessing tool? Using the same "readers" of your resources, why not? Instead of subjecting the user to long processing times, then failures if something overloads or an exception occurs - why not spell out ahead of time that something won't work in a user's given environment.
If Pro is tested in a defined environment or different defined environments - could the comparison be made against the tested environment of a user's machine ahead of running a geoprocessing tool? Why not?
It's pretty simple to get that info running in a command line - it's not rocket science to compare certain resources to those required to run geoprocessing scripts with certain data and such - all the info is there - and it's meta is all readable.
Often we learn during or after the fact that our machinery was not up to the task, or we have to reset parameters - in the Pro documentation, some of this is there and you have to dig to find it - I'm speaking about the CUDA configs and such. Sometimes I believe that we make this more complicated than it has to be, or else the user-perspective is not considered (the real life one, I mean).
Pro is a resource hog, that's for sure. If you trace what's going on using your admin tools or some sort of third party tracing tools, you get a picture of lots of things happening - too many to monitor - and the users should not be having to do this on a machine that specs out by analysis (Can U Run It) that says we should be having a great experience.
All we want is something that works.
So, folks, IMHO, I think that adequate testing by automated testing ahead of this getting into any user-testing, should be detecting the bugs that all the functions might be generating - and then these get corrected ahead of release, ideally. This is possible using simulations of various machine configurations, etc., this much I know. Hopefully, this is happening, but the evidence is that perhaps that needs to be tweaked some, because not all of us are having a great experience.
We also have users out there whose organizations will not allow Pro to be used because of it's issues - IT organizations often do their own testing and nix any software that does not meet minimum criteria for their user-machine configurations. If something crashes a machine in testing, for instance, this would not be allowed for an organization-wide push until that gets sorted out. That's a reality experienced in organizations whose IT governance has tight restrictions about software that is run on its computers. How often will Pro pass that test? Even if it does not yield the products required by users in their jobs as quickly as ArcMap - supervisors will just tell people to not use it. Work demands drive use - and simply stated, it must meet those demands in order to be a widely used software suite.
ArcGIS Pro is our next generation - as we went from ArcView to ArcMap/Desktop, we are all going to Pro. We do really want this to work in real-life work situations. Our old friend, ArcMap has been a trusty enabler of a lot of great work by people. We know that being 32-bit, the more robust 64-bit new kid will eventually take over.
The kinks must be worked out, as they were over the years with ArcGIS Desktop (ArcMap, et. al.).
Obviously, we have a lot of issues discussed here in this thread.
Fact of the matter is - today - that ArcMap is more stable and more predictable. Sure, sometimes it crashes, but mostly it doesn't cause a user's whole system to crash violently.
We would hope that ArcGIS Pro reaches this level of stability and that the resource consumption is optimized to give the best UX - without crashes, without going off into where you're hearing "crickets" and everything goes dim until some undetermined point in the future - or not.
My two cents on the experience. Relating back to the original discussion point - yes, we can't do everything in Pro that we do in ArcMap, but we can do some things that we cannot in ArcMap - but, the teething is still ongoing. Pro is not there yet..
Matthew: I didn't mean to imply that a solution would be simple, but it could be quicker than one would suppose. That's why the reference to a SWAT team is appropriate: a concentrated effort with UX folks and GIS developers would "move the needle"--whereas surveys and blogs like this aren't getting the job done. The puny functionality of ArcGIS Online would also benefit from this approach. Technically, remedies might entail containerizing the app or variants of that technique; there are many options. In the big picture I agree that hard work led to computerized mapping in the first place, and none of us miss drafting on vellum with Rotring & Rapidograph pens--but now's not the time to rest on one's laurels.
If only it were that simple. The underlying structure of Pro is different than Desktop and that's what is hampering performance. Pro is simply designed 'Wrong' to handle large volumes of data efficiently and it relies on CONSTANT communication with 'HQ' and excessive amounts of network calls to validate everything.
'Fixing' Pro would require more than just a few quick tweaks ...it would require taking the lessons learned and rebuilding the functionality on a different platform.
Note: What the heck do I know. I'm not on the Dev team and I'm quite sure I don't know even half of the issues they deal with. So I just want to be clear that I appreciate all their hard work ...even if I'm frustrated by how much harder simple tasks are to complete in the new system.
Jamal makes excellent points, and I'm not even a Pro user yet! Its advantages are tempting but the slowness sounds terrible. Truth be told, ArcGIS Desktop has crazy slowness at times, maybe cos it's running through Citrix here. In any case, the hundred replies here indicate that Esri is not moving fast enough. Esri needs to deploy a SWAT team of User eXperience folks who can pinpoint the flaws, and work right there with the sharpest developers to make the changes. Maybe Esri's business model will have to change, but then again--that's what kept Microsoft from going under: late in the game they embraced Cloud and Open Source and left behind their old Bill Gates monopolizing ways. Esri's bizarre credit structure is hampering progress in the GIS world, and only because Google is too big to bother with the technical GIS market do they survive with little competition.
Yes. ESRI reported to me that it has has found the cause of the labeling performance problems that I reported above and the fix will be in 2.5.
https://community.esri.com/message/893480-re-arcgis-pro-242-in-general-arcpro-has-less-performance-than-arcmap?commentID…
There is reason for hope.
Jamal NUMANI have also started using this ArcGIS Pro and observed its working really slow as compared to ArcMap Application.
Have you received any feedback from ESRI, Way to improve performance
One thing I have noticed immediately perceptible (all releases to date) is that when I browse the local filesystem in ArcMap, it is virtually instant (unless you are opening a GDB with hundreds of objects in it). On Pro depending on what the gremlins are doing behind the scenes it can take several seconds to open a folder with say a dozen files in it.
I just tested a folder on my SSD (Pro 2.4.2) and it took a second of spinning to open the folder of... two text files. On ArcMap (10.6.1) it is instantaneous, just like File Explorer.
What the?
It only happens once per session per path, but if you close Pro and start it, it occurs again. Looks like Pro is indexing everything in the path (perhaps children), choosing icons, reading/caching metadata and previews, etc in the background. Kind of like browser precaching/'speedup' addins.
It's just a theory but explains the orders of magnitude performance loss to ArcMap though.
I'm happy to send you a copy (should probably send me something that proves you have a license for ArcGIS desktop so I don't run afoul of Esri legal).
Oh how I wish I had an old copy of that!!!! Somehow left it somewhere... 😞
Hi Jamal,
Very much agree, sadly a slow and frustrating app despite a lot of hard work that has gone into it. We actually had a call with the Esri dev team about a year ago on this but it was so inconsistent when our support guy demo’d it, it worked ok - probably because he had spent a few hours browsing everything in advance of the call so it didn’t go any further. I think we have to remember dev work on pro probably started 10+ years ago, remember when the ribbon was the hot new thing (12 years ago in Office 2007!), so although new to many users it’s actually quite a mature application. Maybe they have a new app in the oven?
Good Luck,
Rob
David Wheelock are you able to send me an mpk of your 1:3 minute example?
If it's too big for email, let me know and I can set up an ftp site.
Thanks
Here Here for the old and dusty AV3, for attribute table joining, querying, calculating etc. it has no competitors..... Millions of records? No problem....except for the darn 2gb limit! 😞
This is also my experience, but based on some other colleague's experience I think it's due to my hardware which is sufficient for arcmap, but not Pro.
Maplex for both.
Thanks for the examples, David. When comparing labeling performance in ArcMap vs. Pro, are you using either the Standard labeling engine in both, or Maplex in both? Just want to make sure ArcMap isn't using the Standard labeling engine (which is the default) and Pro using Maplex (which is the default).
Kory Kramer, is this enough detail in my slower example?
Sometimes, Pro is faster, MUCH faster.
Sometimes, Pro is slower, MUCH slower.
Example: FASTER
We have an ArcGIS streets export model that runs the Simplify tool as a part of the tool.
Example: SLOWER
I had a user recently request a large, highly detailed wall-map of the city. The map has lots of street labeling. The Maplex labeling performance is much SLOWER in ArcGIS Pro. I wound up giving up on Pro for this project because I just didn't want to wait that long for every refresh while tuning the labeling.
So, as you can see, ArcGIS Pro has it's pros and cons. I expect that ArcMap will have the same experience as the old ArcView GIS 3.X (AV3). As time has gone by and computers become more and more powerful, AV3 has remained static with no further additions, and, so, when it's run on a modern computer, it performs almost instantaneously, in the blink of an eye, and puts ArcMap to shame in some tasks. The same will be true of ArcMap, which is now the static product. As time goes by, Pro will continue to grow and become more resource intensive and require faster and faster computers, and ArcMap will appear faster and faster by comparison, and people will continue to love it.
In fact, I foresee ESRI have a hard time killing ArcMap, a decade down the road. It's so much more capable than AV3 ever was, that I suspect that people will still be using it decades from now.
If you are experiencing delays, it sounds like an installation or pc configuration problem to me. I've noticed this on pc's configured by someone other than the primary user (i.e., general IT staff) and where the user does not have full admin permissions. .... Ensure that you have full admin permissions.
I really hope this is a red herring. It's flat out not possible to enable full admin for all our GIS users. We've already dealt with a couple ransom ware attacks this year that made it inside the firewall. (Thankfully our IT folks caught and quarantined before real damage was done; was very time consuming for them though.) As the perpetrators grow sophistication we're going to have get tighter permissions not looser. There is no reason I've thought of for a user-space program like Pro to require admin permissions.
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:
ArcMap
1.
2.
3.
Completes in 3 seconds.
ArcGIS Pro
Completes in 15 seconds.
Detailing the above will usually help us understand which team is best equipped to analyze the issue.
Thank you.
Totally agree. While ArcGIS Pro does offer many new features and enhancements that are noteworthy, it continues to be extremely frustrating that the performance on a high-powered machines is so poor. Pro was supposed to get better with performance, not take steps backward.
I've been using arcgis pro (both gui and python interface) since it came out....in most cases arcgis pro is faster. However, there is sometimes some unreasonable latency in populating browsing directories in the gui...that seems to happen in both pro and arcmap. Not sure why that would ever occur in the first place given that describing a directory is not a complicated process.
If you are experiencing delays, it sounds like an installation or pc configuration problem to me. I've noticed this on pc's configured by someone other than the primary user (i.e., general IT staff) and where the user does not have full admin permissions. Make sure you have configured your antivirus/malware/firewall settings appropriately. Be sure that you have configured arcgis to access online content without being compromised by antivirus settings. Make sure the directory systems on your pc are structured in a reasonable format (e.g., short directory folder names containing no special characters or spaces). Ensure that you have full admin permissions.
Thanks to all comments.
I did experience opening ArcGIS Pro takes longer than ArcMap, but when I used Arc toolbox in ArcGIS Pro it really works faster than ArcMap.
I'm seeing some useful discussion here. To objectively (instead of subjectively, remember why progress bars were invented) measure performance for drawing using these tools
PerfQAnalyzer: New 10.7/10.7.x Version (Build 173) Available for Download
PerfTools (Build 100) for ArcGIS Pro 2.x is now available for download
Yes I know this does not address other concerns raised about issues with speed of interface and starting tools, but this is at least a place to start with quantifiable and measurable facts. You're not going to get anywhere with Esri devs with "I reckon..."
Maybe deploy that on Git? I can see quite a lot of folks using Git to collaborate on scripts used for benchmarking Pro using perfstat. But it would be helpful if someone more knowledgable started that off. I don't know enough about Git or scripting to pull that off.
Thanks Ian.
No, not on the beta programme. I was a few years ago but pulled out because there's too much distance between that and production. I need to support and instruct users on stable, which means I need to be using the same environment as them. Switching between env's is too attention/time costly.
Matt--you can export these results logs from the "Log View" pane, default is to output to "TestResults.log", but you'll see the option to name and path this somewhere else if preferable.
Re. the metrics themselves--I've seen both faster and slower, both internally and externally, but feedback and collective metrics are useful here. Have you signed up for the beta programme yet?
Thomas--performance measurement is definitely a lot more subjective than simple "pass/fail" routines and we've avoided it until now for largely that reason. Add to the complexity of different peoples' datasets and configurations, which can also compound this.
I'm toying around with the idea of putting some sort of sample project package (i.e. "benchmark dataset", for lack of another term) on AGOL that can be run on different deployments. Again, it would need to be comprehensive and might not target all scenarios, but it's a start. Stay tuned.
-Ian.
Eep, prematurely posted. I was about to add "if we all just reply metrics in-thread like this it's not going to be very useable. Is there an option to format and export the metrics as csv?"
This is very useful, thank you!
Now, how should we share and compare metrics?
For example on my machine it takes 12.8 seconds to open Pro with no project, and 2.8s to acquire a license. Both feel too long to me, but are they unnusual numbers?
------------------ArcGIS Pro Metrics------------------
--- Fixed Metrics ---LicenseTime = 00:00:02.8451996StartupTime = 00:00:12.7988896---StartupDLLCount = 260CurrentDLLCount = 365---StartupLocalDLLCount = 90CurrentLocalDLLCount = 175---StartupMemoryUsage = 342163456CurrentMemoryUsage = 513839104---StartupThreadCount = 57CurrentThreadCount = 55---TotalBlockedTime = 452TotalHungTime = 15297TotalPaneConstructTime = 0TotalTaskTime = 7062---CIMReadCounter = 0CIMUpdateCounter = 0UICIMReadCounter = 107UICIMUpdateCounter = 25
--- Named Metrics ---Startup:Initialize_and_process_DAML = 3902Startup:ShowWindow = 510Startup:Initialization_complete = 3498ProjectLoad:InternalOpenProjectAsync = 7219
Yup! Go for it. Let me know if you get any issues.
I've looked at that as a specific resource for this very topic, and wonder, is there a generic Perftools script that can be provided, similar to the "Can I run it" software checker ESRI uses?
Ian Sims I am on Beta 2.5... will it be fine on it?
As a follow-on to Kory Kramer's comments, I'd like to mention that the PerfTools add-in for ArcGIS Pro is available for download. It's a comprehensive and extensible framework with a powerful scripting language for testing performance of rendering, editing, spatial selection, GP tool execution, and much more. It's just one tool that we run internally at Esri to measure that the performance of Pro isn't degrading as we work towards each release. We update this add-in on a periodic basis with additional testing and scripting functionality.
In the spirit of being transparent and thorough about performance testing methodologies, I encourage those of you that are interested in using this to give it a try.
Cheers,
Ian.
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
I'm currently working with ArcGIS Pro 2.4.2 with 16.0 GB of RAM, 1920 x 1080 screen resolution (important, I believe so) and a x64 system. I can say it working perfect.
Sometimes you must remove your basemaps to experience a better performance of ArcGIS Pro.Nevertheless, ArcGIS Pro is really young and has a long way to act perfectly.
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.
This is the exact experience i have
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!
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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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...
Aurelia, if you let me take a look at your Spatial ETL issues I'll see if I can help improve performance. bharold@esri.com
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.
To confirm, you did this? Just unplugging from the internet isn't the same
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.
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.
Can someone from ESRI's technical support answer these posts?
I'd like to highlight that in terms of ArcGIS Pro, I am really impressed with how it processes ground datasets and how quick other datasets are then draped onto the model.
But when it's taken me 13mins to do Table X and Y to Point, where as in ArcMap, it would process this within seconds, then how does the software give us any time saving or any confidence going forward in completely switching from ArcMap to ArcGIS Pro.
Laptop specifications / performance, or even servers, should be completely taken off the discussion in terms of assessing ArcGIS Pro as a viable product. It simply cannot cope with the simple operations which on a day to day usage, take more time and less efficiency than if we were doing everything back in ArcMap.
I'd definitely agree with this post. whilst processing times may well be quicker in terms of actually running the geoprocessing almost all other aspects are slower. Even something as simple as running 'add field' is much much slower in Pro when compared to doing the exact same thing to the same layer using Map. I tend to do anything 'simple' in map and only use pro for actually running (more complex) gp tools.
Hi everybody,
I agree. ArcGIS Pro 2.4.2 is slow to open, Arctoolbox is slow, even ETL Spatial to make some strong data conversion is "waiting". Network can impact but ArcMap was also requiring network (to write on a GDB for ex).
Creating a global scene is quick but integrating the data is not fast, hundreds of Feature classes, 100millions of points are easiest to use, migrate, analyse with arcCatalog / arcMap. 😞
Solutions is using python...
I also have problems with 3d visualization, but I will open a ticket support for that.
64-bit shall be more powerful, more fast, why that slowness?
I agree. ArcGIS pro is a dog.. I have high spec machine, solid state drives, high end graphics card, work locally and it's not worth using except for the 3D visualisations because I don't have 3D Analyst. Visualisations aren't that good though because you can't control the resolution so very high quality lidar dems and imagery don't look good.
It's painful to click on a tool and wait for something to happen..
ESRI doesn't seem to care about productivity.. I deal with 10,000's of file based data sets for my clients and it gets more painful with each release of Desktop. VBA allowed me to select datasets in my TOC and click a button to process them..
I run my python from Komodo IDE so that I don't have to fire up arc and am starting to use GDAL with C# to save pain.
Kevin,
I can only tell you this much:
We're on a network environment as our company is spread out in different parts of the U.S. License server is in another city.
Running on Windows 10 Enterprise Edition
Lenovo P910
Processor Intel(R) Xeon(R) CPU E5-2687W v4 @ 3.00GHz, 3001 Mhz, 12 Core(s), 24 Logical Processor(s)
128 GB RAM
ArcGIS Pro version 2.4.0
I speculate the issue may have something to do with the networking environment. Yet, ArcMap does just dandy in this same environment. The design has nothing to do with my frustration. I like it! From the many posts I've seen in this thread and in others (See Why does ArcGIS Pro have to be so slow??? ), the major issue seems to be related to network environments. If ArcMap can do just fine in my network, why can't Pro? Antiquated beats new right now in our shop.
What are your system specs and operating environment? What version are you on?
Also how many updates has it been since you installed Pro? I haven't experienced it with Arc yet, but with some software I've used in the past after a few in-place updates I've needed to fully uninstall the software and install clean.
Or is your frustration because of the design of the new software? If that's the case just spend time with it. Once you get used to the design of the ribbons and set up your UI to your liking, I find Pro to be much much easier to navigate than the antiquated look and feel of ArcMap.
Simply put, ArcGIS Pro is frustrating. I can accomplish tasks faster with ArcMap.
I have exactly the opposite opinion: Arc Desktop (10.x) is painfully slow to use compared to Pro to the point I hate opening it. I occasionally do if I have to edit someone else's mxd (since Pro cannot save to that format), but I dread it. My workstation is not very new or high end either:
HP Z240
i7 - 6700 quad core with hyperthreading @ 3.4GHz
16gb DDR4
Micron MX300 512Gb SSD
Quadro K600 1Gb (largest bottleneck in my system for Pro, it's often maxed on both processing and memory usage).
I do versioned edits to an sde environment, AGOL service publishing, as well as a lot of local geoprocessing. The only issues I ever have with speed are when I'm working on a project stored on one of our shared drives which is not on a fast server.
I hav
Workstation Laptop HP Zbook 17 G3E3-1575M:
4 Cores X 64 GB RAM (2133) X 1 TB SSD X 32 GB GPU
Nevertheless, the Pro is slow
ArcGis Pro Map redraw is extremely slow.
I find when working with building addresses on a map: If the labels have a halo (because over an aerial), the performance is unbearable. It is awful. I have to pause the map and export it.
I wish you could learn from the Video Game industry. They are getting 120fps with Ray tracing. I would be happy with 1 fps second, with basic rendering...
I'm not editing SDE databases directly, but many of our workflows edit feature services hosted in AGOL or Portal or connections to remote ArcGIS Server. It could be that the network connection is more of a bottleneck for us than other factors. That might be different if you have on-site SDE servers.
Here's the basics
Dell Precision 3630 - Dell's retail price for this is about $1600
Jimmy:
Do any of your workflows involve editing SDE data? I ask because this is a very important area where my org has found Pro to be much slower than ArcMap.
Can you provide the specs for your machine running Pro as I would like to compare that to the machines that my org currently uses for running Pro? My concern is that getting my org's machines up to your standards would be very expensive and might not be able to be justified.
I have the opposite experience and think this might be due to hardware. I believe a high-performance configuration for ArcMap would be different than for Pro, due to multi-processor support, GPU's etc. On my pc, Pro opens in seconds and is very fast. ArcMap feels like a bag of bricks in comparison, to the point that a rarely open it.
I would agree generally with what Jamal means.
If you create an Arc10 mxd file with all the network connections, layers, layouts, settings etc. and then import the map file into Pro and save out, then reopen both software’s concurrently and try to do the basic same things, most clickable tasks take longer to activate in Pro. The Catalog pane in Arc10 is lightyears quicker to use. I’ve become used to the delay as a fact of life and now use Pro for most of the processing (it is faster) that I do, but IMO the lag time waiting for tools to load, menus to refresh, options to become clickable are a drag on productivity. However apparently, it’s the future we're living with for now.
.
Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
