ArcGIS Pro: 2.4.2: In general, ArcPro has less performance than ArcMap,
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
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.
There is reason for hope. 
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:
- first prod release - unusable.
- Each time a new one comes out, I try to use it more.
- Functions we have begged for, some have been added... Much appreciated when they have...
- But here lately, and according to "Can U Run it" - I should be having an excellent experience - I'm not. Still.
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..
