Why does ArcGIS Pro have to be so slow???

106203
271
08-01-2017 11:31 AM
ericmeyers1
Occasional Contributor

Why is ArcGIS Pro so slow? To select assets, field calculate, display layers, change symbology... the easiest of tasks that are commonly utilized within ArcMap are a drag on the software.

When will ArcGIS Pro become faster than ArcMap? That will be the day it could replace it as the goto product for GIS professionals.

271 Replies
RickGonzalez
Occasional Contributor

Kory,

I will e-mail you as an ftp site would be best.  Thanks.

0 Kudos
KoryKramer
Esri Community Moderator

Thanks, Rick.  I'll look for that email.

Cheers

0 Kudos
KoryKramer
Esri Community Moderator

Rick - the Spatial Analyst team has been looking at this and in the daily builds of Pro 2.4 I'm running the tool on your data in less than 3 seconds.

So it looks like this will be working well with the release of 2.4.  To anticipate your next question (I don't have access to 2.4, what about now?) what you could do would be to run something like Raster to Point which will give you the elevation values for each cell, and then run Add Geometry Attributes on that to end up with x,y,z.  Hopefully that would keep you going until 2.4 hits the streets.

0 Kudos
ThomasColson
MVP Frequent Contributor

Speaking of raster to point, this will do several thousand in about 10 seconds: 

import arcpy
import numpy as np
update_feature_class = arcpy.GetParameterAsText(0)
source_dem= arcpy.GetParameterAsText(1)
elev_attrib= arcpy.GetParameterAsText(2)


if str(source_dem) == 'Twin Creeks: Elevation in Feet':
dem = '\\\\inpgrsms06vm\\GISDATA\\GIS_Final\\data\\basedata\\elevation\\GRSM_10MDEM_2180604\\grsm10dem'
if str(source_dem) == 'Twin Creeks: Elevation in Meters':
dem = '\\\\inpgrsms06vm\\GISDATA\\GIS_Final\\data\\basedata\\elevation\\GRSM_10DEM_Meters_2180603\\mgrsm10dem'
if str(source_dem) == 'HQ: Elevation in Feet':
dem = '\\\\inpgrsms05vm\\GISDATA\\GIS_Final\\data\\basedata\\elevation\\GRSM_10MDEM_2180604\\grsm10dem'
if str(source_dem) == 'HQ: Elevation in Meters':
dem = '\\\\inpgrsms05vm\\GISDATA\\GIS_Final\\data\\basedata\\elevation\\GRSM_10DEM_Meters_2180603\\mgrsm10dem'


rast = arcpy.Raster(dem)
desc = arcpy.Describe(rast)

ulx = desc.Extent.XMin
uly = desc.Extent.YMax
lly = desc.Extent.YMin
#Spatialrefernce
sr = desc.spatialReference


rstArray = arcpy.RasterToNumPyArray(rast)

with arcpy.da.UpdateCursor(update_feature_class,["SHAPE@",elev_attrib]) as uc:
for row in uc:
pnt = row[0].projectAs(sr)
#assuming every point falls to the left and below uperleft corner
deltaX = pnt.centroid.X - ulx
deltaY = lly- pnt.centroid.Y
arow = int(deltaY/rast.meanCellHeight)
acol = int(deltaX/rast.meanCellWidth)
row[1] = rstArray[arow,acol]
uc.updateRow(row)

by Anonymous User
Not applicable

I have found "Calculate Value," "Select by Attributes," and "Excel to Table" to all be painfully slow in ArcPro.

TrippCorbett
Esri Contributor

Hi everyone,

Getting updates on this thread from my earlier comment.  Unfortunately, again only being an Account Manager I'm not technical enough to have specific recommendations on everyone's scenario for resolution, but wanted to pass along some resources again.  If your organization has Technical Support with Esri, I would encourage you to contact them so that the staff can help you look into fixing your individual situation.

This is a great blog post on troubleshooting performance in ArcGIS Pro: Troubleshooting Performance Issues in ArcGIS Pro | ArcGIS Blog that may yield some answers.

This similar thread: https://community.esri.com/thread/121758 also has some commentary from our Dev team with some suggestions and tools.

Finally, if you're working with a central data source, consider putting Pro on a Virtual Desktop Machine (appropriately specc'd) so that it sits closer to the data and has a stronger network connection (in instances where you're seeing the same slowness in ArcMap and Pro), as ArcGIS Pro will work better in a virtual environment than ArcMap will.

ThomasColson
MVP Frequent Contributor

Tripp, I think the universal issue in this an other "performance" threads, is, we're not seeing these issues doing the same thing with the same data sources using Arc Map. And how realistic is "putting Pro on a Virtual Desktop Machine"?

TrippCorbett
Esri Contributor

I hear you Thomas, and that is frustrating.  Unfortunately I don't have any perspective to add as to why it might be happening 😕

There's no point in putting Pro on a VDI if you're not pushing/pulling a large amount of data over your network.  If this is the case however Pro has been improved for virtualization compared with ArcMap.  You'll need a GPU-backed VDI, which can be supported with hardware appliances like this one from Dell+NVIDIA.  Below is a blog that has a lot of useful links on virtualization at the bottom, and a presentation from UC last year if you're considering virtualization:

Virtualizing ArcGIS Pro: Nvidia GRID Telsa M60 | ArcGIS Blog 

http://proceedings.esri.com/library/userconf/proc17/tech-workshops/tw_397-483.pdf 

0 Kudos
AlexZhuk
Frequent Contributor

I've been using ArcMap since around 2001. It was good from the beginning and, with every update, it was becoming better and better. Pro, in my view, is just a one giant failure on ESRI's part. The lack of familiar basic functionality (even zoom tools are all messed up) the ever-changing ribbon bar (added just because it's a  trend?), and is excruciatingly SLOW. In its fourth year, it's still a poorly designed program. My company runs ArcMap in a virtual environment, with all the data residing on a network - and it's fast! A similar Pro setup is pretty much unusable, because no one has time to wait for a week for what used to take a day of work. Just recently I tested out a local setup (app+data) and the performance improvement was noticeably better (not that it made me love it more). But for my multi-user organization this approach is impractical. Sorry for the radical thought, but it's time for ESRI to admit that the whole design is flawed, and start from scratch.

ericmeyers1
Occasional Contributor

I was just talking to one of my coworkers about this, you took the words right out of his mouth. I understand they wanted to integrate 64-bit functionality, which is a step in the right direction, but why did they have to implement the Microsoft model (ribbons)??? Maybe there was no other way to solve this issue... not sure. I would be surprised if ESRI started ArcPro again from scratch. They have too much invested in it at this point. Maybe in a future major release they will redesign the interface, which could improve the user experience. We can only hope