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

[KoryKramer]

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

[ChaseMusgrove1]

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.

[AndrewQuee]

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.

[ThomasColson]

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.

[EllenNodwell_IntegraShare]

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!

[MattWilkie1]

Thank you for articulating so well many of the frustrations I've had swirling in my brain but haven't been able to set down in words myself. I also appreciate that you take time to give kudos to the tech support people who do help as best they can, though unfortunately the refrain from them is more and more "put it in Ideas if you need this worked on".

WRT to the blue-screens and strange errors: accept nothing less than ECC RAM, and Xeon CPU too if you can spec that. Since we've done that for our blue-screen occurences have gone way down. Unfortunately we can't do this for all our users, but we're trying. I can't say for certain this is the cure, but it's worked here.

[EllenNodwell_IntegraShare]

Thanks Matt - so noted on the specs.  We're going to be shopping in the new year... 

What you say Unfortunately we can't do this for all our users, but we're trying. This is so true in many organizations who don't cycle equipment that often and when they do they minimize expenses in doing this - sometimes not speaking with GIS users at all before buying equipment.  This is an art form to get the hardware folks to engage in an organization to understand that the specs are higher for ArcGIS Pro and ArcGIS servers that others.  Yet, this is the wave of the future - along with cloud storage - along with the variants of all of this combined together - everyone's environment configs are different - there is no same anywhere, I reckon.

Thanks again for your response!

[MoahmmedAl_Sulaimani]

how I can try ArcGIS pro 2.5 beta , from where I should install?

[AndrewQuee]

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)

[EllenNodwell_IntegraShare]

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!