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.
Is everything stored locally? (ie not network data files etc)
I don't seem to be encountering any issues with a local install using local data, single user
That is what I’ve noticed. ArcGIS Pro just doesn’t have the network capabilities that ArcMap does. When I move everything local it seems to work fine but when working on the network, it is pathetically slow.
Do you think this is going to be the new ‘recommended’ process going forward? Only using local data for ArcGIS Pro?
Eric Meyers
GIS Programmer, Business Analyst - City of Beaverton
12725 SW Millikan Way, Beaverton, OR 97076
p: 503.526.2404 | f: 503.526.3720
emeyers@beavertonoregon.gov
www.beavertonoregon.gov<http://www.beavertonoregon.gov/>
I am not convinced that Pro is the problem since it is 64 bit, whereas ArcMap is based on 32 bit... It could be
individual hardware and software specs are understated or that the network/server/database requirements are the real problem.
I haven't seen anyone really weigh in on how Pro (aka new-ish technology) plays nice with a 5-10 year old server/database configuration.
I am fortunate to be able to work 'local' and not have to rely on any externalities...
You have clearly identified that it is an externality to your installation that is the problem
I had the same issue with Pro being slow on my old computer and determined it was the outdated video card. Pro wants something with a least 4Gb of VRAM which is separate from CPU RAM. I purchased a new Dell XPS with a NVIDIA GTX 1050 video card (as well as 16Gb of CPU RAM) and now Pro runs MUCH faster..
One particular problem I see is the continuous re-drawing taking place in the Map and Layout views. While Pro is multi-threaded and tasks like the drawing and interaction with other user interface components supposedly largely independent because of this, in reality the drawing taking place in the Map view heavily affects many parts of using the user interface, like the use of geoprocessing tools. I have seen already running tools more or less grind to a halt while the Map was still being refreshed, which with a complex map may actually take considerable time.
I haven’t used Pro much, outside of 3 separate projects. I do like some of the new features but have found some limitations. I’ve also submitted a few bugs already to the ESRI team when using DBMS connections to SQL. I haven’t begun using it for expansive python testing/model building but will see what other issues I run into then. I will also keep in mind what you are saying about extensive TOC items within the map panel.
Eric Meyers
GIS Programmer, Business Analyst - City of Beaverton
12725 SW Millikan Way, Beaverton, OR 97076
p: 503.526.2404 | f: 503.526.3720
emeyers@beavertonoregon.gov
www.beavertonoregon.gov<http://www.beavertonoregon.gov/>
Hi Marco,
I ran across this thread while searching for something else and wanted to point you toward this thread: https://geonet.esri.com/ideas/12579-pause-drawing-in-arcgis-pro. If you look down in the comments, there is a way to somewhat pause the drawing.
Dev is considering a full pause option, but the majority of requests we've received around this are for 3D scenes rather than 2D maps, so I would weigh in on the other thread. For 3D, there are other things you can do as well such as leveraging the new OGC i3s standard .slpk files, and setting reasonable visibility limits when working with heavyweight data so it's not trying to draw all of the time. GitHub - Esri/i3s-spec: This repository hosts the specification for Scene Layers which are containers for arbitrarily la…
Eric,
You can check your machine against what is recommended for Pro here: http://links.esri.com/run-arcgis-pro.
From my user's reported challenges, I know that if you don't have access to a GPU/Video card, your computer is going to be using CPU instead for everything at a poor rate of efficiency, which could be contributing to your experience. If you're running in a Virtual Desktop Instance (VDI), shared GPU aka Virtual GPU (vGPU)=good. XenApp, a VDI without vGPU, or a remote desktop to a VDI=bad. This actually makes a big difference in performance.
I also wrote another GeoNet post here: Best Practices for Running ArcMap/ArcGIS Desktop/ArcGIS Pro on a Mac in Parallels on how to get the best performance when running in Parallels if you're on a Mac.
As Dan mentioned above, network issues could be affecting things, so i3s might help you too.
Sorry I don't have any technical specifics or solutions for you. I'm just an Account Manager who stumbled upon this thread and wanted to provide some info based on what some of my users have encountered.
Hope it helps you both,
-Tripp
I think there is an issue with Pro and multi-threading - as my assumption is that a 64 bit application (that claims to be able to take advantage of multi-threading) should run faster on my machine than a 32-bit ArcMap application. Like the OP, I am also seeing much slower performance with Pro vs ArcMap on my machine. Doing very simple things like calculate field, selecting features within an attribute table, doing edits, changing symbology all take substantially longer in Pro...
As a side note, I am getting crashes when I try to Insert a new map into the project that appears to be in relation to Multi-Threading (but maybe I am wrong on that diagnosis).
Event Viewer shows the following:
Application: ArcGISPro.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ArgumentException
at ArcGIS.Desktop.Internal.DesktopService._IMapAuthoringService.CreateNewMap(Int32, System.String, ArcGIS.Core.CIM.MapViewingMode, ArcGIS.Core.CIM.MapType, ArcGIS.Desktop.Mapping.Basemap, Boolean)
at ArcGIS.Desktop.Mapping.MappingModule+<>c__DisplayClass443_0.<CreateNewMapAsync>b__0()
at System.Threading.Tasks.Task`1[[System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].InnerInvoke()
at System.Threading.Tasks.Task.Execute()
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
at ArcGIS.Desktop.Mapping.MappingModule+<InternalCreateNewMapAsync>d__1191.MoveNext()
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
at ArcGIS.Desktop.Mapping.MappingModule+<InternalOpenCreateNewMapAsync>d__1334.MoveNext()
Exception Info: System.AggregateException
at System.Threading.Tasks.TaskExceptionHolder.Finalize()
My machine specs are as follows:
All my data is local on a very fast 250GB Samsung NVME SSD (so read/write is not the issue here I am afraid). I am also running a NVIDIA Quadro M4000 GPU and ArcGIS Pro 2.0.1, but this issue first started occuring in 2.0.0 - I have submitted countless crash reports.
Our organization has a maintenance subscription so if anyone from support can reach out on this issue, it would be greatly appreciated.
Agreed, it's really the common tasks that were consistently instantaneous for years in ArcMap that all of the sudden are slow in Pro. This is really a spit in the face to end-users.
If these issues aren't present in ArcMap, but are present in Pro, how did they suddenly become "network" issues?
I think Pro communicates with the network more. It would be interesting to compare performance with working on versus offline which is possible in some configurations.
"I think Pro communicates with the network more." is an understatement. Think I found out why every single change to a symbology property takes forever and locks up Pro: Simply changing a symbol from "ArcGIS 2D: Circle 1" to "ArcGIS 2D Circle 3" resulted in 10,475 separate TCP calls evenly split between send, receive, and copy events which took 00:00:02.10 seconds to execute; the same exact operation in ArcMap? 0 TCP calls, 00:00:00.23 seconds to execute. Sometimes the delay is several minutes. It appears that with every symbology change, Pro is re-downloading the entire layer from the source. Why? Arcmap doesn't do this (and isn't as slow at common operations such as symbol styling). Making pure SQL queries to the same data in a variety of clients other than Pro is near-instantaneous. This is regardless of the layer cache settings applied in Pro (I tried all of them, same barely-usable response).
Thomas,
It would definitely be nice to see a real response of ESRI to your detective work regarding the TCP calls or ArcGIS Pro. Whether you are on to something, I can't say, but it does raise questions and points ESRI should look into.
Marco
Hi Thomas,
It would be great if you could describe your scenario in more detail. What steps are you taking before you update the symbology?
How is Pro installed on your network? Feel free to email me at CGaddam@esri.com.
Thanks,
Chait
Just imagine what happens when your network admin put real time virus scanning on your network and local machine and every one of those calls is intercepted by the virus scan before it goes through... The software is rendered useless. My experience mirrors yours in that Pro does generate even more network traffic than ArcMap. Anything that interferes with this affects the user experience and it can definitely be network side monitoring and port limiting.
I have also had this issue with virus scanning. ArcMap runs just fine using data saved in exactly the same location and using the same computer (above recommended specs). This is making it impossible to migrate to ArcGIS Pro as I can't even change layer symbology without the application freezing!
Hi Anneka,
A few question this brings up:
Thanks for any info you can provide!
-Scott
Hi Scott,
I don't know for sure that the speed/freezing issues are entirely caused by my AV software. But having had our IT support investigate the issue, they said that it was isolating and scanning each file every time ArcGIS pro refreshed (or in this case anytime I tried to edit the data, change symbology etc.) The problem appears to be worse when using layers from ArcGIS online or dropbox synced files. Most of our data is synced with dropbox (we're a small organisation and all work remotely) so this can't be avoided. I experience none of these issues when carrying out exactly the same operations in ArcMap... The AV software is Sophos Endpoint. I believe it's possible to set up exceptions, but our organisation has been victim to several attempted cyber attacks recently and our IT contractors are hesitant to do this.
I've submitted a support case so hoping to find a solution.
Thanks!
Thanks Anneka. What catches my attention here is Dropbox. What kind of files are you syncing with Dropbox?
Hi Scott, we back up and share lots of our project files via dropbox, including GIS data. The files are saved to the disk drive and only 'synced' to Dropbox for backup/sharing. I 'pause' syncing (disable Dropbox) when I'm working on GIS to stop it running in the background and only turn on sync at the end of the day to back up any changes. This system has worked fine with ArcMap but is this an issue for ArcGIS Pro?
Hi Anneka, so the actual Pro project files (aprx) are in the synced Dropbox? And as for the GIS data, are you using shapefiles/file geodatabase, or both, and if both, have you noticed that one is more/less performant than the other?
Hi Kory, the project files are usually saved in a Dropbox synced folder, but sometimes (esp if i'm in a rush) they'll be saved in the default folder in another location. ArcGIS online layers are definitely the slowest, but I haven't been comparing shapefiles vs. file geodatabases. I will start paying more attention and let you know!
My organization also uses Sophos which impacts ArcPro. It is a major concern when editing and you can't do anything but wait. I've complained to the powers that be that Sophos is a network nightmare when used with ESRI products.
The high amount of internet/network use does seem to be part of the problem. When I am on an internet connection that is unstable or laggy, ArcGIS Pro becomes almost unusable. This happens even if there are no online layers loaded. It happens even I'm just running a local model and there is nothing at all in the map.
Agreed. This is actually the reason I haven't adopted ArcGIS PRO yet. It's freaking slow and it grays out and takes forever to execute actions when compared to ArcMap. ESRI definitely needs to do something about it. My i7/24 GB RAM PC config is well in excess of the recommended by ESRI and still it's pretty slow w/ Pro.
Also, I don't like having to save a project before I can start playing w/ it. Sometimes I just don't wanna save it ....so?
I agree 100% regarding the hassle of having to create a project before being able to use arcGIS pro. All the time I will go into catalog or arcmap to just add a few layers or look at the attribute data. My role is a developer, so rarely am I actually making final maps. Unfortunately, it looks like this is the direction ESRI wants us to go because some settings/functionality only works if a default database and home directory is set up. Maybe ESRI wants us to utilize software like ArcReader to do this type of work... not sure.
You'll see that Open ArcGIS Pro without having to Save is marked as In Product Plan and we should see this with the next release, ArcGIS Pro 2.3.
I have noticed the slow responsiveness in Pro while using basic tools and functionality. Expecting people in an organization to work locally is unreasonable. We place our data in network folders so that they are accessible to everyone and so that they are backed up regularly. I'm trying to do more in Pro to acclimatize myself with it, but the lag is too much for some of the simple tasks. I end up going back to Desktop for some things. My PC is well in excess of the recommended specs and I have an NVIDEA Quadro card.
I agree wholeheartedly with this as well. I thought the whole point of moving to an enterprise system was to move away from solo databases but pro in a way can be a step backwards. The map documents are now stored locally, causing a runaway solo MXD repository. (
I'm modeling a QC workflow using Pro tasks and the whole first few steps of filtering your data set (which can't be done by task command and has to be done with a python model), selecting all features, and zooming to them takes 5 or more minutes. That's just to get to the data you want to look at. This does not include making edits to the data. Manually, in ArcMap this takes me 1 minute max. I work for a state agency who is transferring all of the data to central network locations so Pro may be a no-go for us now.
"...expecting people in an organization to work locally is unreasonable..." I agree with that. I would also characterize it as unrealistic. I have data all over the place...I would like to have one enterprise database where all my data resides, but that is never going to happen. And if it did happen it would be on a networked server, not on my local machine.
I keep checking in with Pro and these threads, but I do the majority of my work in Arc Desktop because I need to get things done. I was all for pushing through the learning curve for Pro, but I feel that the performance issues are the real reason I end up going back to Desktop.
Yup! Can't stand Pro and is one reason I didn't go to the ESRI User Conference last year. I can't stand that they use ArcPro and push it as if it were the greatest thing ever. IT'S NOT! It's is slow! Riddle me this: when I use the Spatial Analyst > Sample tool in ArcMap I can process a 52 x 32 mile raster grid that is 200 ft x 200 ft coarse in less than 5 minutes. I'm doing the same in Pro at the moment as of this post and it's taking over 25 minutes now and counting! It is too bad they don't have a competitor out in the GIS world that would give them pause to even release a crappy product. Shame on you ESRI.
Rick:
Do you have the ability to create a case with tech support so maybe they can find out what the issue is with the slowness of ArcPro in your case?
Also maybe you can add your vote to this thread:
Four Year Check-In: What is your competency level with ArcGIS Pro?
as well as add your 3 or 4 biggest gripes with the Pro software to give the dev team exposure to issues that existing ArcMap customers are seeing with Pro.
Hi Rick,
I think all would agree that something that takes 5 minutes in ArcMap should probably take 5 minutes or less in ArcGIS Pro. So there is something going on that needs to be investigated.
I think that Michael's idea of working on this with technical support is a good one as there could be many factors at play.
I was curious to see if this is a "generic problem", meaning that it could be reproduced with any data. I created a random raster of 52 miles X 32 miles and cell size 61 meters (about 200 feet). I also created 1000 random points and ran Sample in ArcMap and ArcGIS Pro.
Results:
ArcMap = 1.36 seconds
ArcGIS Pro = 1.22 seconds
I don't think there is anything inherently slower about this operation in ArcGIS Pro. But it would be valuable to investigate the specific performance issue you're experiencing with technical support so that we can understand what's happening.
I wonder if the storage location can play a big part in this problem. I don't work with data on the local c-drive, but I have found file gdb data on a network drive to perform much better in Pro than Oracle based SDE data (enterprise gdb).
Kory - were you using local c-drive data in your testing?
Yes. Local data on C. Yes, "many factors at play" which is why we need to have more details:)
Rick Gonzalez we want to help, we just need some more info, and maybe data. Probably best to move it off this thread, so email me directly and we can circle back to close the loop here.
Kory, do you have setups that you could perform a 'task' on these various storage types vs ArcMap and ArcGIS Pro.
I keep seeing the non-locally stored data cropping up time and again. Is it the nature of the beast? network issues? a communications issue between software and the database?
I have trolled far and wide and never seen any thing that says …. when using X (storage type and location ) expect a Y% increase in processing time compared to using Z (storage type and location)
I know that the operation may have an influence, but you would expect to see some comparison. The one Dan posted from ESRI at least shows that at least 2 of the 4 have 'issues', but Dan's times are even worse than ESRI's
Kory,
Good morning! Thanks for reaching out! I am going to have my IT guys do some research and testing on this soon. If we can’t come up with a solution and will circle back to you.
I will let you know.
Thanks!
Rick Gonzalez
Kory,
Trying to finally circle back to you on this. Sorry it's taken so long. I want to ask, did you you sample the arcgrid to a points fc? That's not really what I was doing. I was just simply outputting a dbf table with xyz values from the arcgrid using the Sample tool under Spatial Analyis > Extraction. Essentially this outputs the xyz values for each of the cells in an arcgrid.
What are you using as the input location raster or point features?
I am using the same raster as under Input rasters. In other words, the same raster I am sampling is also the input location raster. I use Bilinear resampling. Plus, on the Environments menu I set the extents to a rectangle shapefile that is about one fourth the area of the raster extents.
What raster format? Is it in a file geodatabase, .tif, etc.?
Kory, the Data Type is a File Geodatabase Raster stored on one of our network drives/servers.
Below is the Raster information
Rick - also, if you're willing/able to send data and steps directly to me at kkramer@esri.com we can probably take a quicker look. Email me and if we need to set up an ftp file transfer site we can.
Thanks
Kory,
I will e-mail you as an ftp site would be best. Thanks.
Thanks, Rick. I'll look for that email.
Cheers
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.
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)
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: Why is ArcGIS Pro so slow to do anything? 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.
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"?
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
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.
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
I could see all of us, long time ESRI users, complaining about some third-party program, how it goes against all our user's habits and expectations. But the Pro is from ESRI! It feels like the developers just completely ignored and betrayed their users' experiences! I almost want to say "ArcMap was not broken, so..."
Just adding my 2 cents here. If I add sub-types using model builder then it will take much less time than if done via UI. Same action but using alternative way and time is very less. So its still application and not network really?
Just wanted to post this here since it looks like many users prefer the ArcMap layout....you can make an ArcMap-style toolbar for ArcGIS Pro! This blog will show you how, along with other tips and tricks: ArcGIS Pro: Ribbons, Toolbars, and UI Hacks
Also, here is a link on how to translate common workflows from ArcMap and it's equivalent in ArcGIS Pro: For ArcMap users—ArcGIS Pro | ArcGIS Desktop
Hope this helps ease the frustration!
Ashley
Well said.
I do greatly appreciate some of the increased functionality of, and access to cartography tools, and like that masking isn't buried four of five menus deeps. However, I've just begun using ArcPro outside of webinars, or workshops, and my first instinct now is that the ribbon design is going to take so much more clicking in repeating workflows that require more than one ribbon. I did find where you can make your own ribbons and sections within that ribbon (customizations, like in ArcMap), but I haven't yet determined if building my own ribbon with common tools will overcome the inefficiency of the ribbon structure. I'm beginning to wonder if it was really necessary to take away toolbars. I also greatly agree with another comment about projects. I often open ArcMap and view data without ever saving the mxd. Requiring a saved project will create so many junk projects.
Agreed!
I to have found Arcpro to be effectively unusable, its too slow, crashes and I'm having issues of not being able to update feature classes. The ribbon user interface looks good but is painful to use. The arrogance of knowing what you are doing dictates what you can access directly, I'm for ever hunting and changing through the various ribbons to access the functionality I want. It also takes up a lot of screen real estate...
Time for reflection and words of wisdom from Dilbert on software alternatives
I was having a terrible time with Pro hanging up and crashing and just being excruciatingly slow, even on fairly basic 2D maps just panning around and zooming. I used the frame rate display (Shift + E) and the Diagnostic Monitor (Ctl + Alt + M) and found out that I was having major "hangs" and it was using Direct3D. So I switched to using OpenGL in preferences, and it has made a huge difference. It was basically unusable before and now it is not too bad. There are still spots where it is slower than I'd like, but overall it is at least as useable as ArcMap for most day to day things.
I don't know why it made a difference, as I am only working on 2D maps and you wouldn't think the GPU would matter, but in my case it definitely made a big difference. I'm on a laptop which has a basic Intel graphics card and also an Nvidia card, and depending on what you are doing, it uses whichever card is best for power vs performance. Maybe when I was on Direct3D it wasn't even using the Nvidia card, and switching it to OpenGL forced it to use that graphics card (?). I don't understand it, but it worked for me. (For now, anyway...)
It's a pity.
I simple cannot get to enough time to explain and describe everything that makes me cry using ArcGIS Pro. It would be a long, long story of crying. Nobody will hear long, long story of crying, I understand that.
I thought with the 2.1.1 update I would be able to see at least some of improvements. Nadda. Niente. Nix. Null. Zero.
It is very disappointing for me. And very frustrating at the same time, because I am the guy who should bring ArcGIS PRO workflows to our company.
And I simply don't understand ESRI.
Ever since downloading ArcGIS PRO I have been having issues with ArcMap and PRO. I re-downloaded and installed both programs again today; last time was this past August. This process consumes an inordinate amount of time.
.
Today I attempted multiple times to export a joined table to a shapefile and geodatabase. The Copy Features tool stalls at 6% and hangs there for hours until I close down the program and reopen it.
ArcMAP will no longer do an optimized hot spot analysis on point data, no explanation at all. I then take the same data with the same process, and it works fine in ArcGIS PRO..
It seems to me ArcGIS PRO intends to be a money machine for ESRI. Charges for every analysis supposedly in ArcGIS online only. Does anyone else have negative credits on their account?
Working with ESRI products has become increasingly frustrating over the years. I believe they are focused on the development of their offerings and silo their subject matter experts inhibiting a manageable integration of the parts into a workable whole.
The bottleneck created by the software hurts my brain, decreases efficiency, and inhibits creativity.
Note the effort to export the joined file referred to above was completed: "Start Time: Tuesday, March 27, 2018 4:52:35 PM
Succeeded at Tuesday, March 27, 2018 6:09:20 PM (Elapsed Time: 1 hours 16 minutes 43 seconds)"
David, I can feel your pain. That will not help you, though, I am aware of it. With this answer I try to give you moral support, I cannot more.
Unfortunately, I experience everyday the same or very similar issues, geoprocessing window stalls, freezes and all you can do about it is to restart the whole operation (and I am not doing any rocket science here).
It is very disappointing for me and I am here even not speaking of fundamental leak of most profound and simple functions in attribute table, which is to my understanding completely useless at the moment. And this moment lasts for years now. And ESRI lets us vote about it.
As you said, it hurts my brain. Altogether with explanations of ESRI staff about why is it so and how good and thoughtful that ### voting is for us small users...
Sadly, I don't have got so much time, to participate in ESRI social games, say user support in their way. I have to work for living in the meantime. Paying and using ESRI GIS software every day.
Keep smiling, hoping for better future!;)
So this is Pro 2.2 for over 10 minutes while doing nothing other than "Download Map". Happens with all of our feature service, which, BTW, download in less than a minute in Arc. Frequently pushed the CPU into 99 and 100% territory and caused extreme sluggishness when doing something else (e.g read emails while waiting forever for Pro to complete a task). Not entirely convinced this 64-bit capability is an improvement.
I am beginning to suspect that the 8 Gb recommended is the new low.
What else are you running in that example?
One tab of Chrome, then all of the background processes. I have numerous examples of stuff like this, as well as a few TS cases on the topic. But yes, while 4 cores and 8 GB returns as "Recommended" in the "Can You Run It" app, what I'm seeing in testing on over 1 dozen workstations is that translates to "Pro will start but don't expect to get a lot done". FWIW with I think one exception, these are all SSD's as well. For a large org, where Arc Map ran "decently" on the Etch-A-Sketch email checkers we normally get, telling IT that we need to start getting 3000$ Etch-A-Sketches is as likely as two raccoons in a bag of feed corn getting along....memory prices have spiked pretty high lately.
Thanks for sharing.
I'm experiencing similar results.
I've also noticed that PRO crashes regularly if my memory (which is 32GB) exceeds 50% for more than a minute.
I've noticed that when I start accumulating a lot of Layouts and Maps within a project that the project takes longer and longer to open. Right now I have a project with about 30 maps and 25 layouts and it takes twice as long to open as projects with fewer maps and layouts. I had planned to use the same project for several years but at this rate I may need to make "versions" of my projects in order for them to open in a reasonable amount of time.
Finally, I know PRO uses the GPU and I have duel Nvidia Quadro P1000's, but drawing time seems on par with ArcMap - which seems ridiculous. I make pretty complex land maps so I expect they'll take some time to draw, but a totally re-written product like PRO should draw faster than the legacy product it's replacing. Ideally it would draw MUCH faster.
Exact same problem here... Pro was great for the first week... then as project accumulated maps and layers loading was prohibitively long to the point I had to move back to ArcMap. Really horrible and disappointing.
This type of issue where the aprx is around for some time and is getting more complex over time is something that ESRI needs to test more thoroughly. Whenever you open an incident with ESRI to replicate your issue, they use a fresh environment so they most likely won't see the issue because they will not let the aprx linger around or make it more complex.
They REALLY need to work on performance.
Its one thing to force users to re-learn workflows and figure out where tools are in the new system, (or if they exist), but when you do that AND the base performance is equal to or less than the legacy product, its a MAJOR problem.
I've been working primarily with Pro now for about 4 months. There are a few things that I like, and a few "directions" where I see they are going in the right direction even if they aren't quite there. (For Example: I couldn't stand Legends at first and I still think its anything but "intuitive", BUT, now that I've built a bunch of layouts and I understand where to find things - Legends are heading in the right direction....)
Unfortunately, there is far more I'm VERY disappointed with. Performance is probably top on that list but even beyond that they've made the UI more cumbersome in some ways. For example, they have migrated workflows that were simple operations in ArcMap into tools that you have to run in PRO. Select By Attributes and Calculate Field are two process that feel more clunky in PRO than in ArcMap - and those are CORE functions. They might fundamentally be about the same but the interface itself takes longer in PRO. At first I thought this was because I hadn't gotten used to it yet, but now that I've worked with the program for four months I've confirmed that it's just not as easy to use as ArcMap. And don't even get me started on how terrible editing anything in a table is in PRO! It's almost unusable. I edit tables in ArcMap.
I'm hanging in there and fighting through the performance and changes but I'm also exploring QGIS as an alternative for at least some workflows. The interesting thing is that even while learning from the ground up in QGIS, the performance and difficult UI in PRO makes learning QGIS roughly similar in terms of time spent. Plus I get to expand my skill-set.
I find that in Pro, even simple maps with only a few layers is very sluggish. Even just clicking a layer (and doing nothing else) causes the spinning wheel. Right clicking to open an attribute table, and then scrolling through the attribute table is just horrible in Pro, whereas in ArcMap its highly responsive and fast.... I have installed Pro on two different computers with the exact same results. Its not my local settings, its Pro.
Pro development team really needs to do better - Pro needs to be faster and better than ArcMap. Despite the nicer interface and more diverse symbology options (which is great!), at the end of the day, if the program isnt at least as crisp and responsive as ArcMap, I get less work done. I work in the private sector and efficiency/quickness with UI interactions is highly important to me.
I like the last sentence!
To me the frustration stems from the perception that ESRI expects its customers to QA/QC their products for them by submitting arduous and time consuming bug reports (and replications) to support. That might be fine for public sector workers, but I work for a for profit company and time is money.
We pay a lot of money for ESRI products and the level of bugs and issues that go out the door and then remain unaddressed (especially in pro) is unparalleled in my experiences with other software companies (like Adobe). One example is that when opening a project, snapping remains on even when the snapping button (in Layout) is turned off. You need to cycle the button twice before it actually turns off. When the project is saved after snapping is turned off, it gets turned on again when you reopen the project (with the button showing its off). Every time you open that same project you need to cycle the button a couple of times. This very obvious bug has never been noticed by the dev team, despite being there for now 2 or 3 major patches?
The snapping example may not seem like a big deal (and its not) but its indicative of what I can only assume is an extremely poor QA/QC process that I can only imagine is there to save money.
There is also an issue with symbology updating causing Pro to crash when you change the data source of a layer, which has remained in Pro gosh, since 1.0.x, despite bug reports that I took valuable time to report.
Tyler:
Can you provide a link to the symbology update bug in Pro thread as I would like to try to reproduce on my system in 2.2.0?
Take a raster, apply a color ramp symbology to it (in my case I use "classify" symbology). Change the source to another, different raster (right click the layer, properties, change source) and see if that causes a crash. Its as if the classes that are set with the old raster dont match the new raster and Pro crashes because of it.
The work around I have found is to remove the symbology (back to "stretch") on the raster and also hide the symbology pane first before changing the source and then reapplying the symbology after you have changed the source.
The reason I am changing sources instead of adding new data and applying symbology that way is because I have many layers setup as templated symbology styles where its very quick and easy to simply change the source of the layer (and preserving the symbology) instead of restyling all the symbology every time. I also employ saved symbology layers (.lyrx) and apply symbology to layers that way as well.
I have had similar issues with polygon feature classes (like block groups) using the same process, but its less frequent and inconsistent. I am not sure where to find the thread you mentioned.
Tyler, does this crash for you on 2.2? I followed the steps you provided but Pro doesn't crash.
Could you send me example data and steps to reproduce so that we can take a look?
Thank you!
Kory Kramer I was able to repro and crash. I'm CC'ing you on the dump.
Tom - you said you repro'd so I tried again with the second raster as a layer in the map and got the crash. Will get this to the framework team right now to analyze. Thank you!
Kory,
I just tested as well and I am still crashing and its reproducible. Where can I find the crash dump report and how do I get it into your hands?
I outlined the process in my post above. Raster in question is a raster derived from Kernel Density using various UTM projections (depending on what part of the country our study is in). Perhaps I need to capture a video to better show you whats happening? Let me know on both of those points.
Out of all the crashes I get, this one is the most common and most frustrating so I would love if we can get this resolved.
Pro v2.2.0
Thank you!
Thanks, Tyler. I really apologize that you're experiencing this crash. I was able to reproduce it, so we have the crash dump file - not necessary to get anything else from you at this point.
Of course we never want to see crashes, but when they do occur, please fill in the error report along with your email and a description of what happened. This can help if we end up needing to reach out for more info.
More here: Report software errors—ArcGIS Pro | ArcGIS Desktop
"Error report files have the extension .dmp and are saved to the application data location on your local hard drive, typically C:\Users\<User Name>\AppData\Local\ESRI\ErrorReports. The 10 most recent reports are saved."
Thank you.
Yep, filled out the error report probably at least 100 times for this exact crash and Ive watched multiple versions come and go with no acknowledgement or fix
Tyler, you talk out of my heart. Every single word you say is true.
Now, they want me to be more constructive in my complaints. I understand that. But, the matter of fact is, even if I want it (which I do), I don't have got that time. Simply as that. In my work, I am heavily involved in software development and I can say, that is a lot of time and many mails to get things right and done. I cannot see how could I do that for ESRI.
And for what? Yes, to participate in their work free of charge, still paying a lot of money for a working software. Like in good sense of ESRI community. No problem, I can do that- one day when I get some time, when I am not in work and when I am in the mood (not resting exhausted of my own work).
Except for, when I see how much they care year after year about what all of us users write, I get progressivly out of that mood. And that could be a problem.
Cheers!
I just did a Pro training course. For simplicity, I took our (admittedly elderly) dual 2.2GHz, 4Gb Windows 10 laptop. This has run Desktop (many versions) perfectly fine for years along with a suite of other GIS/DB tools, and seemed to work okay with some basic testing of Pro after installation.
Once I loaded up some tutorial data for exercises, it was agonising. 99+% CPU usage, most of the GPU and perilously close to thrashing page file (I shut down everything possible to shut down in Windows) running consistent 1.5-2GB RAM usage. It was basically unusable, 1-2 minute waits to do anything in Windows, and I could see Pro literally rendering every object second by second.
Sometimes it just gave up and said "meh, close enough for government work"
This was with a few tiny tutorial datasets and the web basemap/hillshade.
I didn't even dare trying 3D seeing as Pro was unable to even handle a file explorer dialog. After falling further and further behind the class simply because Pro does not run on a Desktop-capable computer, I gave up and ditched it for my workstation (2014 quad 3.4GHz, 16GB) for which is was fine, although the NVidia Quadro struggled a bit with frame rates in dynamic 3D.
Looking at what it was doing, I think Pro is spinning up a large number of background processes/services which eat up resources (geoprocessing handler, job handler, etc.) I could also see it dynamically building displays, panes and elements, sometimes rejigging them in real time as things opened and changed to get the desired layout, so there is a lot of work going on under the hood which is much more demanding and sophisticated than Desktop. Every time you click on something it is running through a whole set of rendering/workflow/data management dependencies.
For example even something simple like opening an attribute table. In Desktop, bang, open pane with first X lines, done. In Pro it was doing some kind of indexing, analysis, calculating different font sizes, column width etc to make it all 'look nice' before opening the table, and then of course depending on docking it had to resize multiple other objects and re-render them as well.
Short story: Unless you have a fairly new computer, expect that you will have to upgrade it to run Pro.
"For example even something simple like opening an attribute table. In Desktop, bang, open pane with first X lines, done. In Pro it was doing some kind of indexing, analysis, calculating different font sizes, column width etc to make it all 'look nice' before opening the table, and then of course depending on docking it had to resize multiple other objects and re-render them as well."
This is precisely my experience as well. But its not completely because you have a slow computer.
Even with a very fast computer, it runs slow. As you mentioned, it seems pro needs to re-render and reprocess everything anytime you click. I am running an Intel i7 2.8ghz with 16gb ram and an NVME SSD hard drive and I get the spinning wheel anytime I click something in pro (and this is the second computer Ive run Pro on). This is not acceptable.
Are you able to submit that very obvious performance issue to tech support? I see pretty much the same thing.
Will do
I'll just add that both computers used above are standard (not premium) SATA SSDs and all the data, OS and temp data was on them, not a spinning platter.
We're looking to go to M.2 NVMe for our next hardware upgrade, based on where high-end gaming is going. How do you find this works in a GIS environment?
It doesn't. Having to buy a gaming computer in order to run GIS software that previously didn't need a gaming computer is "unsustainable", quoting the folks that I had to ask for $ with which to buy the computers....to your specific question, I think you'll get more ROI on faster processor/more cores versus a high-end NVMe drive.
Oh of course, it's cpu-bound, I could see that easily. I was interested in how you found the technology compared to contemporary storage.
We've had the same issues with cost. Senior managers have difficulty understanding that a bog-standard micro desktop suitable for government form-fillers with some light Excel, Word and Outlook use is completely useless for GIS/geoprocessing. We've actually had replacement requests knocked back because we "don't need a gaming/multimedia laptop" or even "you don't need a laptop, you can use a desktop" (for field work?) and had to escalate back up the chain to get the hardware needed for the job.
Even ICT doesn't get GIS and big data/processing requirements. In the last PC roll out they dodged the question of backups and when I complained (while they were decommissioning machines) we had sixty 1TB drives to copy they said "there isn't enough network capacity for that, just back up your data to usb thumb drives" *snort* Sure....
Replying to myself, how narcissistic!
Ego aside, here's an update for those interested in the hardware side of Pro requirements. We're about to replace our Dell Precision quad-3.4GHz 16GB with Lenovo ThinkCentre hex-2.4GHz 16GB (don't ask why we are 'sidegrading', public service)
Of particular interest is the comparison between the 2014-era consumer Liteon 256GB SSD on SATA and the 2019 prosumer Samsung 500GB SSD on NVMe.
I won't go into the other benchmarks but they are roughly comparable as shown. As you can see above even though Passmark is just a synthetic benchmark, the performance difference between the two SSD models is dramatic, and remains the same regardless of the other hardware configurations (all Lenovos had the same class drive) as shown below.
This results in a smoother and more responsive experience in Pro, making up for some of the possible disadvantages of the system. Based on this and initial testing I would highly recommend adopting M.2 NVMe in your next scheduled upgrade. I still haven't rebuilt my gaming rig (shame, all I can run is Warframe. Badly) but I'll update you with the results, although that example won't be so clear cut as there's more variables beyond the primary drive being changed in support of *ahem* real-time dynamic rendered entertainment suites.
Finally, if you don't have the opportunity to move to NVMe and must stay with SATA (for example, you do not have M.2 support on your computer) be aware that even all 'standard' SSDs are not the same. Samsung (and others) are built with different tech it seems the big difference is that QLC ram in the Samsung QVO is cheaper but less durable than TLC ram in the Samsung EVO, max speed also drops.
Ref. "MLC vs TLC vs QLC: Why QLC Matters"
tldr: Replace your old SSDs with TLC-SSDs for maximum performance and durability. For Samsung this is the EVO gamerspec model, not QVO desktop model.
This article was not sponsored or endorsed by any of the manufacturers mentioned and remains my subjective and probably worthless opinion only.
Edit: Added world benchmark link for the Liteon in case you thought I'd accidentally benched my optical drive (yes the Dell Precision has one). Who knew Liteon SSDs were even a thing? Surprise!
ESRI, it's a shame that we have to have discussions like this four years after the product was introduced! Not all of the us, users, have enough time, chance, clout or privilege to test and choose hardware. Most of us work with what's available. With ArcMap, all we had to ask our IT was "Give me enough RAM" (if that). I have stronger words to express my feelings, but...
This forum thread is like an echo chamber. But it would be really interesting to know how/if ESRI going to address this problem. I'm wondering if someone is addressing it during the User Conference?
To be blunt and to the point, the only way it's going to get addressed is via tech support. I have at least 2, and more in the pipeline, cases just on performance. SDE performance. Blowing up my CPU cooling fans. Some GP processes take twice as long as AM. The so-called "recommended" hardware in fact is "barely start Pro" specs. Here's how this works: I have an SDE case, and they find that the Transmorgifier, only present in a few customer environments, is generating excessive SQL queries to the bunny rabbit. You open your SDE case, and they find that the Supercalifragilisticexpialidocious Equalizer is spinning in the wrong direction if you installed Pro on the 3rd Wednesday of an odd month while it's raining and you forgot your lunch. You share this on GN, and I discover that my Supercalifragilisticexpialidocious Equalizer doesn't spin at all. These are things that no QA Test Plan will ever discover, and no intern in the test lab is ever going to think of. So, instead of one customer ******* and moaning to TS about SDE (me), there's now 2, or 4, and they have enough SDE Intercepts and Traces to actually change some code. But, don't be discouraged about sharing your experience on GN. I probably solve half my problems on GN based on ya'll's input, which keeps the TS lines open.....
I posted it already somewhere before - a major redesign of Pro is needed. But it's $$$$$$$$$$.
Loved your explanation.
I'm of the same mind with Tyler. I'm frustrated because even though we've all paid for completed software I think we are experiencing incomplete and extremely buggy software.
UI testing and QA/QC needs to be on the developers time and money, not the Users.
It says something when I'm taking time to learn an entirely new (to me) open-source GIS system because time-wise I'm getting a similar ROI to what is supposed to be the new flagship product for the GIS system I've used for 17 years.
(FWIW - I've already spent a LOT of time on Tech support calls too. I'm hoping that all of that time will help them make improvements. However, it's disheartening when they still haven't fixed basic performance issues like table editing in 2.2).
Thomas you bring up a good point that there are some things, so specialized, that no QA/QC team will discover, and I accept that.
I think that ESRI should incorporate SDE data from multiple types of databases (SQL Server and Oracle) into the Pro training classes (currently they use file gdbs), so the trainers can see first hand some of the slowness issues that Pro clients are experiencing with these more complex datasources. I think then internal ESRI people might help to persuade ESRI management to focus more effort on improving the base product instead of focusing on bells and whistles for tools in Pro that only very specialized GIS people use.
My company has the same issues. EVERYTHING runs slower when on a network. I do not understand how, in this day and age, this is a problem and why it is not being addressed immediately. We have been working on a network slowdown issue for a year with Esri to no avail.
1.4 works fine but when we upgraded to 2.X everything dragged.
Couldn't agree w/ briertel more. Why have read/write speeds slowed down with the 2.x version of Pro?? It has made the product completely unusable since our team continuously shares projects w/ each other over our server and are accessing 5+ gb of data.
Changing symbology of a SDE point feature class in Pro 2.2:
Note how long it takes. Looking at wireshark logs while this is occurring, an incredible amount of traffic is going back and forth to SDE. Why? Because in Arc Map, I can change the symbology 5 times in the same amount of time it takes to change symbology in Pro. And guess how much back and forth is occurring with SDE when I do this in Arc....not much...
Performance gets even worse when you turn off caching for a map layer, which was the solution to BUG-000113527 ArcGIS Pro Attribute pane fails to dynamically update data for values calculated through SQL for published feature services.
The result of the bug that I logged on this in 2.1 is "Implemented in 2.2", so I'm hopeful that others in the community are experiencing this same specific issue: "Changing symbology in Pro takes 2-10 times longer in Pro than the same exact SDE data source does in Arc" and can get some attention on this issue that, judging from the other posts in this thread, probably affects a very large number of enterprise customers. I plan to reopen the case, but expect a "cannot reproduce" outcome......
Thomas... so the issue seems to be with how SDE and Pro interacts..
ArcMap, you suggest, behaves nicely with SDE?? all the time?
Do you have issues with locally stored data?
I am trying to get my head around who is the 'villain' in all this
In terms of data access, locally stored always is faster, in Arc and in Pro. However, with locally, there are other Pro performance issues. I just used what I think are one of your Py decorator examples to time stamp some common GP tasks. Everyone of them is slower in Pro/Pro Py. Neither behave nicely with SDE all of the time, IMHO, it's just Arc Map "chatters" less with SDE than Pro does. That much is evident from numerous traces, profilers, and perfmon counters. Back in the good old "T1 Line" Days, you couldn't even connect to a remote SDE with any ESRI product. So a lot of this is function of your WAN speed, but, like I exemplified above, even on the same LAN connection (a 7 MB VPN today), Arc outperforms Pro.
Thomas:
Besides Wireshark, do you have the ability to monitor database activity from Pro with TOAD software, as I don't believe Wirehshark provides details about database connections. I say this because in 2 different Oracle databases (one SDE, one spatially enabled with SDE ST_Geometry libraries), I am seeing many more database connections in TOAD from Pro than from ArcMap. For 1 user connection in ArcMap, there were 3 or 4 user connections from Pro. Have you seen phenomenon such as this in your extensive testing of Pro.
No, the only other thing I've used for SQL benchmarking is GitHub - clinthuffman/PAL: Performance Analysis of Logs (PAL) tool , but not for this issue. TOAD looks like it has some cost to it, which would take about 97 years for me to get through the approval pipes and levers.
Tom, I realize that you are working on this as a case with technical support. I think you've referenced the Can you run it results earlier in this thread. But can you share the specifics about the video card from the machine where you captured those .gifs?
And yes, the video driver is the most recent.
Thanks.
Same behavior whether I assign Pro to a profile or not.
How can this topic be marked "ASSUMED ANSWERED"? This thread has been going on since August 2017, multiple people are experiencing slow down issues.
Can someone from Esri PLEASE tell everyone what they are doing to solve this crucial issue?
I'm the owner of the thread and I don't even considered it answered... seems like ESRI just set it to that for me. I was looking for a way to mark it back to OPEN but couldn't find anything.
Do you want it marked as a Discussion? (that can be done)
It is getting stale-dated and given the version changes since the initial post. Let me know.
Well, Esri staff (and others) have been replying recently so I am hoping it is still on their radar. It should be marked in whatever way makes them address the issue asap.
Has anyone reported this as a bug?
I believe several cases are open on this issue, I have a few myself. Unfortunately we're in "Cannot Reproduce" territory, but discussing at least weekly as we churn through different test and logging methods. Which leads me to: it would really help me, and others having the problem, if you'd log a case and have good steps to reproduce in Arc and Pro that show the same task in Arc not showing the performance issue versus the same task in Pro.
I will say, applying a blanket "Everything is slow" won't get a lot of attention, my cases focus on two very specific tasks, with the idea being that there is one specific cause that will resolve all of them. ESRI has acknowledged "There is no question you're having a problem" based on hours of screen sharing (with one analyst saying "I don't see how you get anything done"). So far we haven't gotten close to the "glaring and obvious problem", so again, if you are having a problem, love to see your details on GN but I'm hoping one day ESRI will call me and say "User so and so submitted this SDE case and we found the problem! Here's the fix...".
1 888 377 4575, Option 2, Option 1, customer #......
Thomas:
Do you have any idea if the ESRI analysts you have been working with think the problem is database agnostic (Does not matter whether its SQL Server, Oracle, Postgres, etc.)? I only ask this because I have logged bugs with ESRI in regards to SDE and Pro that are specific to Oracle. This has also been the case in the past with ArcMap. Bugs that apply across multiple DBMS would probably get more attention from ESRI than bugs that are tied to a specific DBMS.
So the user has to sacrifice display quality in order for Pro to perform normally? Doesnt seem like a realistic solution at all.
Pro runs slower when working on a project on a network. Period.
Even if you lowered the display settings it would still run slower than if you ran the same project locally.
Just in support of your comment if you hadn't seen it already, further up the thread Thomas Colson reported seeing some pretty intensive network usage for simple operations.
As Thomas just discussed general whinging "it doesn't work good" will be passed over by Esri. What we need to do is show provable and replicatable examples of how it does not perform properly in specific cases, and how there is a demonstrable difference between Desktop and Pro in the same operation.
I'm sure Esri is already doing/has done this, but once isolation tests are done, you can get down to specific cases and the parts of the application causing issues can be optimised or fixed. Probably what is happening (or what we often see as GIS developers) is that one minor issue conflates with some other issues and maybe a bug, or sporadic problems with the OS/network/database to create a noticeable performance problem.
What the user sees is "doesn't work/grinds slowly" but actually solving that can be more complicated than just fixing one thing.
Not passed over, just not actionable. General whinging is really frustrating for development teams.
Absolutely! This is productive, but admittedly, is the hard part that may (will likely) require time troubleshooting on the user side if we cannot readily reproduce a performance issue from a given description.
We are committed to continually improving performance and we'll be much more successful accomplishing that by working together to get to the cause. Thanks for the balanced assessment Andrew Quee
Nothing to do with all the network issues, but I've had a pretty good performance boost by turning off all the antialiasing options, and setting rendering quality Low in the Options--Display menu. Might be worth a shot for everyone following this thread.
Thanks for that. I thought those options would depend only on the GPU - I was running 40% load most of the time so I didn't try them. I was consistently CPU bound, pegging it to 99%+ for the whole time.
Worth a shot to test though. If Pro is using the CPU to render graphics and ignoring your video card's capabilities, well that explains a lot, in particular why this thread exists.
I am working to update python scripts run with ArcMap 10.5.1 to python scripts run with Pro 2.2.1. I am noticing output differences from geocoding which will necessitate updating the python scripts and while researching this topic by performing the geocoding process manually in either ArcMap 10.5.1 or Pro 2.2.1, I have noticed that ArcMap 10.5.1 (the old 32-bit software) is significantly slower than the latest and greatest Pro 2.2.1 (new 64-bit software) with this geocoding process.
Starting from a table with approximately 222,000 records I get a geocode throughput of 28 million records per hour for ArcMap 10.5.1, but only 15 million records per hour for Pro 2.2.1. The computer running the Pro software exceeds specs in all areas, so I'm wondering if there is a configuration issue with my geocode setup to cause it to be twice as slow as ArcMap (I would think it should at least be equivalent if not faster)?
I have a few examples of GP-Tool -> Python stuff working slower in Pro than in Arc that I'm not quite ready to share yet, however, might I suggest moving your PY question as new one to the Py section, where Dan Patterson will likely have an answer before you post it!
Are your GP Tool performance issues complex compared to just running the Geocode Addresses tool on a standalone table in my test case? I ask because I would be interested in testing your GP tool scenarios in my environment to see if I encounter the same issues.
Your idea to publish AGS services directly from Pro should be available with AGS 10.7 as per ESRI product manager. Would your org be able to upgrade to 10.7 quickly after it is released (a few months) or does this type of process take a considerable amount of time (6 months or greater)?
I'll share with you my toolbox. It's the same one that I've used in a couple of cases. Incredibly complex!
On the 10.7.x thing, we have a loosely enforced "check it before you wreck" it policy in the datacenters, which I myself follow strictly (as I'm the one usually doing the testing and certification), which will soon be a non-negotiable rule, with perhaps as long as up to a year or more before a new enterprise version gets rolled out past testing. For example there was a M$ issue with 10.6.1 that caused us to put the brakes on testing, and now I'm certifying and finding a few more minor issues (that' I'm not quite sure of yet, and will sit on them 'till I can repro them).
Just to chime in - in my case I was having similar issues. I access all data over the network. I finally discovered that my layout must have had a corrupt element. This seemed to affect many aspects of the software even when not working with the layout. I simply exported the layout from catalog, deleted the layout from catalog, then reimported and now the software is working really well. I hope this might help someone.
Thanks for sharing, Jeff. I don't suppose you'd have a project with a "bad" layout anymore?!?!
Sure you can grab a copy of the empty project here
Dropbox - Demo_Corrupt_Layout.aprx
It doesn't really exhibit noticeable issues until you add a few dozen layers. Doesn't seem to matter if it's local or network data. It gets progressively worse with more layers.
The most common issue I would face with this project is UI hangs. For example I would get 30-45 seconds of UI greyout after doing something like "make this the only selectable layer". Drawing speed has always been fine.
Once the layout is completely removed from the project the issues are gone.
I hope this helps a bit with your research. I would appreciate a follow-up if possible.
Kory Kramer I haven't tried to repro (it looks like the issue might be happening when there are 100+ layers?), but:
Note the commas and spaces in the path and that the path is populating:
Thanks Jeff Meyer and Thomas Colson. I'll try to find some time to look into this more today and will report back.
Jeff - from what I've looked at, it isn't clear that this is dependent on the project you sent.
I open a fresh project and when I have a number of layers in a map (like you said, maybe several dozen) I see severe hangs when making a layer the only selectable layer, or collapsing all of the layers to not show the symbol...
Looking at this with the development team. Thank you for providing some tips on how to reproduce the hanging.
Kory, while you're on it, could you please keep in mind, and possibly take this up with the same dev team members, the performance issue and suspision I raised concerning "Tasks" and toolvalidation in Pro:
ArcGIS Pro: Stop queuing senseless "UI Tasks" (performance issue)
This may be related, and I have never heard a definitive answer of you whether this was actually being looked and worked on seriously by the dev team, while I think it should.
Thank Kory - let me know if you hear anything. Our jurisdiction is watershed based with over 2000km2 of large scale data. Rendering speed is always lightning fast which is why I rolled it out for my users. I didn't anticipate all the UI hangs, or whatever is happening.
Would you know if the corrupt layout was imported from ArcMap or created brand new in the Pro project(s)?
Wanted to add my two cents since this thread still seems somewhat active and I have not seen a solution anywhere that solved my “Why is everything so slow?” performance issues. In my case, it turned out to be OS settings.
I added ArcGISPro.exe process and common ArcGIS file types to Exclusions in Windows Defender. This solved the biggest issue of AntiMalware Service Executable sniffing and dramatically slowing down all incoming and outgoing connections. This helped performance especially for network hosted datasets. [Windows Defender Security Center > Virus & threat protection settings > Add or remove exclusions] You might have a look at other antivirus/malware software that could be scanning files actively used by ArcGIS Pro and add exclusions there as well.
Next up was graphics performance. Downloaded and installed latest drivers for graphics card directly from manufacturer. Windows update was not automatically updating for me. Set graphics settings to “High Performance” for the ArcGIS Pro application. This will make sure graphics processing is done by graphics card if available, rather than CPU.
For other laptop users, you should see a slight improvement when setting power mode to “Best Performance”. Not sure if this is an option with desktop version of Windows 10.
This won't help every case, but might be a good place to start if these settings are at defaults.
For most organizations, excluding anything from security controls is not an option, and not something that had to be done with ArcMap. We have the same AV problem with ArcGIS Server: AV scans of the install directory slows it to a crawl.
Thanks Matt. Never thought of this. I'm going to give it a try.
I've been looking at pro for the last years. Always same conclusion: that it is too slow (mind-blowing slow). I remember going from arcview 3 to arcgis, and this is not the same user resistance issue.
As an arcmap user I had the same wish list as everyone else:
- multithread - to speed things up with my multi-core cpu
Result: pro is unbearably slow
- antialiasing - to see things as they print or make better presentations
Result: it does anti-aliasing, but is so slow I can't use it
- 64 bit - I want to use more memory to be faster!
Result: pro is unbearably slow
- several layouts in a project - I want to be more productive, have less projects for a single task
Result: pro is unbearably slow
- cartography/symbology - I want better/more rules so I am more productive and can avoid complex layer/scale range/symbology setups (same layer loaded multiple times, different query defs, scale ranges, symbols)
Result: pro is unbearably slow
So the result is - I can't get the good stuff that would make me abandon arcmap. As time passes and arcmap gets further behind I'll be looking at the competition for a new best-in-class GIS desktop product. I already found one that offers all of the above items (QGIS). If esri doesn't/can't make a good product I will move on. I'm a client, I am not a fan. I owe you money not loyalty. You owe me quality service.
Thanks @Duarte Carreira for this post. I was already thinking I am alone. I would like to write a post on my own, but there are so many things I would like to address about this sloppy thing called ArcGIS Pro, that I simply cannot find the time for that.
Unfortunately, ESRI is completely wrong in so many ways related to this issue and they whether don't get it or don't want to get it. It is really pitty.
Wow! And to think, they will keep peddling Pro at the ESRI User Conference as if it was the best thing ever. I laugh at them the last time I attended UC when they smiled and smirked about its 64 bit capability. No, Mr. Dangermond! It's a useless product! Maybe we need a quiet revolt at the UC and say enough is enough; challenge the presenters and developers on its lack of performance! ESRI, please take back Pro and keep ArcMap!
Hello,
I want to re-iterate what Michael Volz just replied. I had opened a ticket last month with ESRI Premium tech support, and used the ‘Select By Location’ tool as an example in that case. The simple selection I was doing was selecting the parcels on a remote SQL Server with one district polygon – ultimately selecting a subset of about 200 parcels. In ArcMap this operation takes about 1 – 2 seconds, but in Pro it took over 8 minutes on my end. Thankfully ESRI could reproduce the error (faster than 8 minutes, but still unacceptable) and the results are below. They have logged it as a bug and will send it on to development. The issue seems to be working with any remote database….Pro is very chatty and slow in that regard.
Overall, I like using Pro and use it everyday, but I agree that the performance needs work still, and this issue is preventing us (LA County) from fully switching over. Like has been said earlier in the string of this post, if we all work with Tech Support on different Geoprocessing tasks then they will get a loud and clear message that the software needs further configuration. This Select By Location task was just one example, I've had performance issues with joins, exporting to excel, spatial joins and other fairly straightforward Geoprocessing tasks.
From ESRI…
File Geodatabase: – ArcMap 10.6.1: Less than a second. – ArcGIS Pro 2.2.4: Less than a second. – ArcGIS Pro 2.3 Beta: Less than a second.
SQL Server: – ArcMap 10.6.1: Less than a second. – ArcGIS Pro 2.2.4: 3 minutes, 45 seconds. – ArcGIS Pro 2.3 Beta: 3 minutes, 9 seconds.
Oracle: – ArcMap 10.6.1: Less than two seconds. – ArcGIS Pro 2.2.4: 3 minutes, 57 seconds. – ArcGIS Pro 2.3 Beta: 3 minutes, 25 seconds.
PostgreSQL: – ArcMap 10.6.1: About 3 seconds. – ArcGIS Pro 2.2.4: 1 minute, 43 seconds. – ArcGIS Pro 2.3 Beta: 1 minute, 3 seconds.
Thanks,
Dan
Dan:
I'm not sure you have data that can be tested like mine, but I have a bug created for SDE performance in Pro for a specific scenario (no editing involved which is even slower) that you can try replicating with your data.
I have a fairly large feature class with about 28,000 records that has a relationship class to a table with about 5,000 records. One of my auditing steps to find orphan related records is to select all the records in the feature class and then open the related table where it would have all the related records selected. Any unselected records are orphans. This operation can take anywhere from 20 - 50 seconds in ArcMap 10.5.1 but consistently takes 3 - 5 minutes to execute in Pro 2.2.4. The bug for this performance issue is BUG-000119165, which if you can replicate then you can ask to be added to this bug. My hope would be that the more people that can report the same issue to ESRI, the more likely ESRI will attempt to address the issue.
I also hope that whatever ESRI finds to be the root cause of this problem, will dramatically increase the speed of editing SDE data in Pro as well which would be a major step to the adoption of Pro in production for my organization (instead of just being mostly sandbox software).
HI Michael,
I will try a similar workflow you described when I find time to do so. It's good to hear that you've logged this as a bug and it sounds like a similar situation to mine. I share your hope in that more people will report these issues to ESRI and send a message about these performance problems that a lot of us are having.
Thanks,
Dan
I tried your workflow on my system, but I did not see the drastic performance issues that your data show, so it would be interesting to see how slow my workflow would be on your system. When you say your server is remote what do you mean exactly? At my org the servers are located at a remote location, but are connected by fiber so the throughput is very good (I'm not sure of the metric on this though). How is your remote server connected to your network as this could be part of the issue?
ArcGIS Pro is SLOW, really SLOW. That's a fact and it means it's not a case by case issue. It's a general issue; every user has noticed and experienced how slow Pro is. At this point, ArcMap remains the number one Esri's products. I believed that Pro was supposed to run next to ArcMap and ArcCatalog on the same machine! At least, that was what we were told. If so, why would 8G works fine for ArcMap and not for Pro? Far from being technical, let me flatly say that ArcGIS Pro thinks too much before executing any type of geoprocessing. It is frustrating. You want to turn a work over to your boss ASAP, ArcMap is the way to go, sadly.
However, don't get me wrong; I like ArcGIS Pro concept. I use ArcGIS Pro frequently, I like using it. It would have been a game changer had Esri not rushed its release. It is an unfinished software. The base architecture needs some works not patches. Honestly, ArcGIS Pro is a user-friendly software once you familiarize with it; and it has great potentialities as well. Things you can easily do that are quite daunting in ArcMap: things like editing, 2D to 3D and vice-versa, data sharing, ArcGIS online connection, Tasks, Link Views, and much more.
I would like to finish by saying that what Esri needs to do at this junction is take a step back, re-work the whole ArcGIS Pro project and come up with a more robust and efficient replacement for ArcMap.
Hi Ezi,
Can you describe this further: "let me flatly say that ArcGIS Pro thinks too much before executing any type of geoprocessing"
I am guessing that you mean validation in the tool is taking too long for a tool you are running? After you input some values into a geoprocessing tool, and before the tool is run, the framework evaluates that the values you entered are valid given the requirements of each parameter. If you can provide an example of a tool or tools that take a long time to validate in your workflow we will look into improving them.
Thanks,
Drew
Ezi Molley I completely agree with you.
And I'm going to vent a bit more now...
This is not a very specific case scenario where we have to help debugging the situation and provide as much reproduceable data as we can to tech support. arcgis pro does not fit in that situation.
We are not talking about exotic setups or workflows. Everyone knows pro runs badly always. This is basic QC responsibilities and someone is knowingly let the product get out to the public like this.
Any guy/girl at esri with a common PC will encounter the same issues we are all facing easily.
Please don't tell me you don't know about network performance or you didn't detect the glaring rendering and geoprocessing issues. Don't tell me you don't make performance baseline testing. I know you do. Just look at the excellent System Design Strategies site. It's all there.
So to me this is a question of honesty and transparency.
So my message to esri is this... own it.
In truth, arcgis pro is free of charge. So there's a tolerance for a slow, informed, programmed switch from arcmap.
Key is informed...
Stop avoiding the real situation and start showing good leadership.
Tell us what you intend to do about it, even if it's nothing at all.
You could tell us that it's an intrinsic characteristic of the new software, and it will be slower than arcmap for some hardware generations to come, that eventually will catch up.
Just like going from av3 to arcgis 8 back in 1999 (it was staggering slower).
Tell us to buy real top-end machines, with raid nvme disks, cgi pro video cards, max frequency 2 slots cpus with 20 cores, and min 128gb ram.
At least we wouldn't be surprised that pro doesn't budge on our measly i7 sata sdd 32gb rigs. We wouldn't waste our money like this anymore.
And/Or you can tell us that you have an optimization plan going on and will include performance improvements in each iteration of the following releases.
And, please, in either case, create a knowledge base document on how to mitigate the existing performance issues. That would be helpful.
You can start by acknowledging the problem and point to the road ahead to solve it.
Be a leader.
That would win over *all of us* instead of alienating most of us.
I agree.
Except, the transition from 3.x to 8.x was a breath of fresh air! It was an exiting change!
As I already said in one f these discussions, ESRI would be better off by scrapping the whole Pro thing and starting something new from the beginning (and ditching the ribbon the process). After 4 years of struggles, it should be pretty clear that the Pro is a flop, sorry.
Duarte Carreira, thank you for this post! I agree 100% with you.
ESRI, I am so sorry I cannot get to some quality time to address all issues I have with this piece of ... software you call ArcGIS Pro. Unbelievable how ignorant you are, year after year. I am truly sorry for that.
Hi Vladimir,
I just messaged you. Please reply to me so that we can collect your thoughtful and constructive feedback.
Thank you,
Kory
Hi,
This thread is enormous! I do encounter performance issues which are unacceptable. In the meantime, I found an interesting (short) thread which greatly improved speed:
Improve Field Calculator Performance
I tested it this morning and it is much much better. To me, slowness issues are most of the time linked to GUIs. My issue this morning was about Calculate Field performance. However, I had similar problems editing annotation with Attributes pane open, which considerably slowed things. And I suspect updating symbology is a similar problem but I don't know how to update symobology with no GUI opened...
Hope this help some of you.
Get some RAM Bro! 16GB is nothing!
Hi everyone,
I have commented on the performance of Pro in the past - both on per operation performance as well as the frequent increase in steps compared to Desktop when required to perform a task.
I see Esri is still avoiding the issue and diving into very deep specifics any time an issue is raised.
My still standing summary to Esri is: Use Desktop & Pro in the real world to perform a range of steps to create maps, data products and related tasks and measure the outcome in metrics such as number of clicks, amount of mouse movement required, GUI draw wait time & process run time as well as overall project run time.
In some aspects Pro is miles ahead of Desktop - I exclusively use it for any workload relating to publishing to Online. For bureau-style cartography and almost all data management I use Catalog & Desktop - often with multiple instances of each open. The Pro approach to editing in the attribute table is deplorable.
There is a common misconception that you need a serious machine to run spatial workloads in Pro.
You need a serious machine to run Pro. For 90% of my workloads Pro, its overhead and associated serious machine is not required. As an abstract comparison we are getting told we need the latest & greatest machine to run the Steam client. Many games themselves can run on average hardware but without going overboard with ram, cpu & graphics you cannot get to a point to actually play the game..... It may be pretty but if gets in the way it has to go sit in a corner a little while longer.
Kory Kramer For some people the latest Windows 10 update 1809 may help.
On two of my machines the update has made general network browsing quite a bit faster - diving into a mapped network drive folder in Catalog in both Pro & Desktop is much better after the update.
Take note that 1809 will break quite a few things in AutoDesk's 2019 products.
This sums it up nicely. Development team needs to really run both pieces of software side by side and if Pro isnt at least equally as efficient as ArcMap, then they need to fix it. Running a GP tool to select by attribute/location, apply symbology from a layer file among many other tasks just didnt take that long in ArcMap, nor was it needing to be run as a GP tool... It was near instantaneous and very efficient.
Editing an attribute table is so incredibly clunky and inefficient compared to ArcMap.. ex: it resets the position of the attribute table every time a record is editted, needing to manually scroll back to the next row/column/record which needs to be edited (where in ArcMap hitting return takes you one record down-no need to rescroll). This is basic software development 101 and should have been caught by now... It makes me wonder what the development team is thinking...
Its a bummer because Pro has a lot going for it, especially the plethora of new Symbology options available with the additional transparency functionality, and just overall easier symbology editing experience (no more windows within windows within windows). I also like the new layout and legend UI and find it much better for cartography. Which is why I still do all my analysis in ArcMap and do map exports in Pro, because ArcMap is faster, but Pro has better cartography options.
Is the development team aware of these issues and just dont know how to fix them? Or are they are just completely unaware of the issues... Im not sure which is worse. All I know is that Pro should not be less efficient than ArcMap to do the basic tasks I have mentioned - running a GP tool that takes 30 seconds to do something that once took 1 sec is just unacceptable. People are not going to adopt the software if thats the case... At best, they will only use Pro for certain tasks but still primarily use ArcMap (like me).
Kory Kramer I have just update to ArcGIS Pro 2.3 and came across an excellent example of changing something without thinking about performance and efficiency.
When you Share a layer as a web service and select the "Configuration" tab you now need an extra click to open the most often used settings for a Feature service.
I can understand why adding a WFS section is useful and why that may be a click away but why reduce efficiency of a menu item that is used so much?
The funny thing is that if you want to go to the WFS section from the Feature section you have to click back (on the left side of the window) then click to open the WFS section (on the right side of the window).
Maybe they should divert the UI & UX work experience students into another part of the business.
Thank you for the specific feedback, Chris. I'll share that with our UX team.
Adding a field using the geoprocessing tool took me 10 min. That's quite a bad performance, specially when in ArcMap it takes not longer than a minute. Would be appreciated a better performance, especially when you force to use ArcGIS Pro, like with UPDM Data Model. Working with it is a nightmare.
What kind of data source are you seeing this slowness with (e.g. SDE data, file gdb, shapefile, other)? Is this add field operation slow for all types of data sources?
I have been using Pro for some time, and I like a lot of the editing features. However, changing symbology is so slow.
I am using SDE (Server 2008), with versioned feature. I switched from single location, to unique values, added two fields, have 10 symbology types. To get to this point it took 10 minutes.I have the map paused, so it is not needed to change the view.
Now I am going through and changing the symbology to match what was used in the past. I am now 40 minutes into the change. I change the line type. It takes about a minute to minute and a half to "update". Then I click properties to change the color, dash, offset, and it takes about another 2 minutes after the apply button is pushed.
WHY IS THIS OCCURRING?!?
It shouldn't take 1 hour to replace 10 symbology types.
When the program is running idle it is using 0.5% of my CPU and 0 Mbps of the network
When I click apply it uses 8.8% of the CPU and close to 45 Mbps of the network
It also pulsates the usage, 10 to 15 seconds of use then 10 to 15 seconds of idle, and so on until it refreshes.
I am using ArcGIS Pro 2.3.0
Processor: Intel Xeon CPU E5-2620 v3 @2.4Ghz
RAM: 16.0
My throughput on my network to the server is 1000 Mbps
Come on, please fix this very basic function with ESRI.
SQL Server 2008?
Microsoft SQL Server database requirements for ArcGIS 10.7 and ArcGIS Pro 2.3—Help | ArcGIS Desktop
Is it possible to upgrade to a supported database version, run through the same steps and circle back here with results?
I made an error on the server, we are currently using 2012. We have the most current version of server/portal on our system (Just updated 10.6.1). This has always been an issue with pro. There was a great video imbedded in this thread that shows the significant decrease in performance when changing symbology.
We are in the process of updating the server to Windows 2016.
We are experiencing the same thing and we are running SQL 2016. My PC and video card more than meet the requirements. If everyone who has been posting here is complaining about the same slowness and bugginess, perhaps esri should take it more seriously and stop treating user complaints with such a laissez faire attitude. Something that costs as much and promises as much as Pro should just work out of the box. The user environment shouldn't be such a huge issue in most instances. If you want users to convert from Desktop you have to prove that Pro won't be more of a hindrance than a help.
Tracey,
there is no such thing like "...if you want users to...". They don't tick like that. We all will have to abandon ArcMap sooner or later (rather sooner). No choice left whatsoever. That is the fact.
And yes, ESRI doesn't have to do anything, history learns us. They let us vote, play around, that is, bread and games. Again, you hardly have got a choice without major and painfull changes in your organisation, if you come to the cheerfull idea to switch GIS platform to anything else than ESRI. It's not that I would recommend that.
Cheers!
I have been keeping an eye on this thread for a while now. I thought at first that something was wrong with my set-up or network configuration etc., but after reading all these comments I see that the problem is definitely with Pro.
At this point, I am using Desktop for everything up to layout, then I switch to Pro as my layout tool and import my mxd from the Desktop. Any kind of analysis, adding or calculating fields, selections, editing or creating Annotation I do in Desktop and then bring it over to Pro. I find that I can go back and forth pretty easily when I find something I need to change while I'm in Pro. I just leave Pro open, change what I need to change in Desktop and then refresh in Pro.
Not the best solution, but at least it keeps my workflow flowing.
Zach,
This is similar to how I work but how do you handle Legends in Pro? The lack of default legend properties and the way properties are changed (lots of menus and clicking to get to the property I need to change) is really time consuming compared to ArcMap.
Also do you have Layout templates that you import your maps from Desktop into? Right now since you can’t lock layouts in Pro, if I want a new map and layout in Pro I literally have to copy a similar map, paste, and rename and then import that into a layout template (also copy and pasted). Its clunky compared to ArcMap but it could just be my workflow.
Just wondering how you are handling a new layout using an existing map. (I’m a one man shop and what I’m doing “feels” correct, but seems really awkward coming from ArcMap. At first I figured it was growing-pains learning the new system but I’ve been using Pro for 80%+ of my work now for 9 months and it still feels awkward).
I really appreciate seeing descriptions of how people handle their workflows – even the simple ones.
Thanks,
Sean
I'm still feeling my way with this workflow--it sounds like you have more experience with Pro than I do.
I actually like the legends in Pro. After I figured out that I can make different layers visible or not in the legend by clicking in the TOC I am pretty happy with the legend.
What do you mean by 'locking' a layout? When I get to the layout stage and get the map zoomed and centered where I want it I always make a bookmark, usually named 'Print View'+scale. I do the same thing in Desktop. Then if I activate the layout for some reason and zoom/pan around I can always get back to my layout view.
I'm just figuring out how I want to deal with maps vs layouts in Pro, so I don't have a real good best practice for myself yet.
What I mean by locking a layout is making changes to a map and layout combination for a specific task without needing to created both a new map AND Layout when in ArcMap an .mxd drove both.
For example, I’ve got a map template built for a Size A Power point map (which is really common around here). I’ve also got a Size A Layout Template that goes along with the Size A Map Template. I use the Map Template as sort of a “starting Point” where I tailor the map how management wants and then marry it to the Layout Template. (This way all font and symbology sizing works for the size requested). After making the requested changes I export a .pdf or a .emf or a .jpg depending on the requirements of the end product. This work flow requires that each time I received a new request that I make a copy of the map template AND a copy to the layout Template. I must rename both to the name I want for the new map that is required, and thus my project grows by a new map and a new layout for every request I get. (Often I’ll need to revisit old maps to make revision up to years later).
In ArcMap, I also had a Template – an .mxd. I’d take that template and make one copy, adjust the Map view and layout to specs, export to .pdf, .emf, .jpg and All I’d have is another .mxd. Basically it’s one half the “bloat”.
Both workflows accomplish the task – but ArcMap felt more streamlined since it generated ½ the files.
Regarding Legends: I like the functionality that you describe (re-ordering and whatnot) but that’s where it ends for me.
In ArcMap because I just changed elements I needed in the maps and the Layout was locked to that map, I’d never have to re-create a Legend but in Pro because I want to maintain my map template, I need to copy the map, and I want to maintain my Layout template so I have to copy that.
This requires I build a new Legend each time versus having my Legend dynamically update.
When building a new Legend there are no options for a “legend template” so I have to change all legend settings every time I make a new Legend.
In ArcMap since all of my Legend settings were tied to the .mxd, I set the legend settings once and that was it.
Building a new legend in Pro without any template means that every time I do this I need to dig into the settings, set my border properties, background properties, border and background offsets, All Fonts, My Legend title, font-settings, and alignment. Further there is no way (that I’ve discovered) to universally set the font. I have to go into Legend>Title>Font Settings, Legend>Headings>Font Settings, Legend>Labels>Font Settings etc – for every legend setting. Most of the time the font is ALL Tahoma in the legend, but other times it’s all in another font and I can’t figure out why. I don’t necessary mind the UI for the Legends settings if I could set all of them once – for all further layouts, but there is no way to do this (that I have found).
Sorry for the long reply – hopefully that makes sense. So much of what people do in Arc products relies on the industry and the organization itself within an industry. I make all paper maps, but many industries are all digital. In some ways Arc is the Swiss-army of data/maps-representation-of-data. Its understandable that a new flagship programmed from the ground up may not accomplish the same task more efficiently in every possibly way. That said, it feels like ESRI didn’t research real-life work-flows as thoroughly as I’d have liked and threads like this one seem to be proof of that especially as more and more people work on switching over to PRO.
I do appreciate Kory Kramer and other folks efforts sorting through all of these complaints. I just wish PRO felt like the big step forward from ArcMap that we were led to believe. There are certain UI improvements that feel like they are really heading in the right direction (especially if the program was as snappy and quick as we all hoped). Unfortunately, as this thread points out, improvements to speed are lacking. Not just in the specifics mentioned here, but in a LOT of places.
I’ve noticed PRO acting slow when I copy elements in Catalog and Paste them like in my example above, When I change Labeling settings, even when I close a project (like why don’t we have an option for Close and Save the project – one button and done). I can open multiple layouts at the same time but each needs to open – which takes time – and then when I click on the tab – it has to draw which takes more time. I can’t export multiple layouts at the same time so when I make a series of maps that all need to be /pdf’s – I have to run through that export procedure for each map, wait for it to generate the .pdf, and then do the next one. I should be able to export X-number of layouts at the same time to the same format, and close my project while those are exporting. The project may run in the background till those exports are complete – but It should “release me back to Windows” without a wait.
This has turned into a rant but I know others in this thread will empathize.
That said – I reached out to you about specific work-flows because SOME headaches might be alleviated by sharing with one another how we accomplish even basic requests/Tasks using PRO – and anything we do for each other is something ESRI is at least partly off the hook for.
Thanks for sharing your workflow!
Sean
The font issue is indeed frustrating.
I made this positive update to ArcGIS Pro 2.2.1 painful slow using Basic License after ArcGIS Pro 2.3 was released.
The issue with the Basic-license underperforming vs. Standard-license might be of interest to some of you as well:
All in all ArcGIS Pro is evolving into a stable and productive application for us.
@Thomas L,
In my experience, slow opening and saving in Pro is directly, and linearly, related to the memory consumption of Pro. Pro in its current state, needs copious amounts of RAM / Virtual Memory compared to ArcMap.
I have some very complex topographic map style Map document with hundreds of Query Layers accessing a PostGIS database. ArcMap manages to handle these documents in its 2GB memory limit. Not Pro... The bigger the underlying database in terms of GB storage, the bigger Pro's memory consumption.
I have seen Pro consume up to 70GB(!) of memory (my laptop only has 32GB RAM, so rest is consumed as Windows "Virtual Memory" on disk). Such documents take up to 10 minutes to close, simply to release all the used (virtual) memory. I have actually monitored this process, by opening the Resource Monitor from the Performance TAB of the Windows Task Manager. Pro will not close until it has released all this virtual memory, and during this 10 minute waiting time, I slowly see the memory consumption of Pro decline in the Resource Monitor until the app finally closes when almost all memory has been released.
I therefor think this is not really a memory leak, but "by design"... probably combined with to conservative releasing of memory during application use, meaning Pro does not release its memory even if it could or should. I do think ESRI should have a closer look at this memory consumption issue of Pro. Having Pro consume anywhere from 5 to 30x more memory for what is essentially the same map document (I literally import ArcMap documents in Pro), is worrying to say the least.
Marco, for this complex mapping project, have you experimented with putting some of your layers in a base map layer? This seems like an ideal use case for using that functionality. I wonder if it would help with your huge amount of memory consumption.
No doubt, especially if a raster basemap is created. Reducing 400+ vector layers connected to a PostGIS database to a single raster layer, will surely take the memory usage down to next to zero, but at the cost of a huge amount of processing time to create a raster tile cache.
And this is no solution for high quality vector output to e.g. PDF, which is my main interest at this point. And there is the added problem, that there seems to be no current option to retain the full complex symbology in a basemap. All options seem to drop at least part of the complex symbology and labeling options (e.g. vector tiles), or don't allow high dpi raster tile output so you sacrifice quality. Neither is particularly appealing to me at this point, especially also since my main interest is outputting PDFs as I already wrote.
Can this be moved to a bug, improvement, something..... This still had not gotten any better when utilizing an SDE. Especially when the basic functions are slow, selecting by attributes/location. Editing is fine and love it, but get the other functions corrected.
I recently attend to version a data set, add global id, and Editor Tracking. It took me almost 10 minutes to get this accomplished using my desktop, connecting to our Sde on a 2016 server. This use to take, 1 maybe 2 minutes using arcmap .
Can't even try to traverse a line. Enter the Direction/Length and it takes a solid 20 seconds to update and display the change. I only have 127 more lines or ~42 minutes remaining for an operation I could do in 5 minutes in ArcMap. And that is just to enter the data. Don't forget trying to split polygons using those new lines, and then editing the attributes for each polygon. 2 hrs later for a single map correction.
Forget about making a mistake and having to undo, 3 minutes later the menus finally stop being grayed out...
Try to delete a line, menu grayed out.
Hit Enter to input another line, menu grayed out 20 seconds.
Everything is locked up right now and I haven't even done anything substantial.
Well come back today and try again. Pro actually responded pretty darn well. Nearly what I would expect from the next gen platform. Not quite there, still some lag with menus, but I was able to traverse the entire parcel pretty efficiently.
Did yall come in and mess with my machine overnight?
It occurred to me that one of the things that could bog down Pro (especially on a machine that has limited CPU) would be the auto-indexing capability. It is somewhat unclear to me from the help article exactly what gets indexed, but if folder connections are auto-indexed by the scheduler, that could slow things down. One thing to try is to turn that off and index manually (or set it to index at a time when you know you do not use Pro [but are logged in] during your daily routine.
Update the search index for project items—ArcGIS Pro | ArcGIS Desktop
Konfiguration: 64bit W7, 8GB RAM, Intel i5 @3,1-3,3 GHz
a.)
no other Programm running than Arc GIS PRO 2.3
1 shapefile (GADM) imported into project's file geodatabase = 256 features
project stored on local USB3 drive
new column "area_sqkm"
task: calculate geometry: takes exactly 38 MINUTES
finished without any error messages, values visible in attribute table, stored project
re-opening of project not possible: damaged database
b.)
compared to QGIS: less than 1 minute, no problems
"project stored on local USB3 drive" is your problem there. Arcview 3.2....Pro 1789.345 (coming out in 500 years) will never work when accessing data or project files off a USB, not even USB3.0.
Hmmm... I run a +500(!) GB PostGIS database based on OpenStreetMap data for the whole of Europe of an external USB 3.1 connected (sometimes over 3.0) 2TB Samsung EVO SATA drive in an Oracle VirtualBox instance running Ubuntu as guest system for PostgreSQL (the USB drive is connected to a Core i7 HQ quadcore laptop running Windows 10).
I think you are underestimating what can be done with a reasonable drive, but I do agree having a newer faster NVMe drive instead of SATA, probably will boost performance.
USB3 is capable of 5Gb/s, which is much faster than most people's network connections, and as fast as many SSDs. USB is not likely to be a bottleneck in this situation.
This thread is getting hopelessly long and becoming hard to follow but I wanted to add my two cents. I too have really struggled with the "slowness" of ArcGIS Pro. It has many great features but even the most simple tasks seem to take much longer in Pro than ArcMap. The typical response from Esri seems to be contact Support. In my experience this has just been me going in circles trying to figure out what is wrong and Esri Support just guessing. I did not have this experience with Support with ArcMap. I know very little about system architecture so don't really understand what it means to be multi-threaded but if this is what multi-threaded means, then it is not a good thing. I also saw that network connections are to blame. I would venture a guess that the majority of Esri users have their data "on the network" because they run in an Enterprise environment. This is something that Esri has pushed for years by the way. I've specifically noticed that even simple geoprocessing tasks that would have taken seconds in ArcMap take 30 seconds plus in Pro. For example, joining a table to your data requires a geoprocessing window to open which usually has a delay and then after making the appropriate changes to the script, pushing run still takes several more seconds. Individual tasks taking seconds longer is no big deal but a series of them really adds up over the course of a day. My more recent experience has been with working with Excel tables in Pro. That is a totally different topic but still relates to poor performance in Pro. This process has been quite painful and has resulted in hours of frustration even though I have been following the advice in the Help section.
Josh, the join performance example that you bring up is something I think the development team is already looking into depending on the specifics of your case. When you run the Join, what does the actual processing time show?
I've seen cases where a project may have multiple maps, layouts, tables open, etc. and the perceived lag may be due to the application syncing back to all threads. So maybe that is what you're seeing, maybe it isn't. Could you let us know?
Also, depending on what the details are behind your comment about working with Excel in Pro, ArcGIS Pro 2.4 will see a revamp in Excel support which should make it very similar to how Excel is read in ArcMap.
Kory,
Here is the latest example. I wish mine was only 0.78 seconds. Now, to be fair, this was the one with the Excel table. I believe I did have a number of multiple maps, layouts, and tables open. I have since closed most and only have the required map and layout open but the overall performance has not improved. The multiple tabs open is about convenience, if this feature was working well it would be a major enhancement from ArcMap due to the ability to see multiple maps and layouts at the same time but it does make sense that that could be a contributing factor to lowered performance. Also, thanks for your comment about Excel at 2.4. I am looking forward to it.
Also, note again that this 7.84 seconds does not count the time it took to open the tool in the geoprocessing window which was probably several seconds more at least. I can only guess at how long that part was.
I also see the following the roadmap: Geoprocessing leveraging spatial databases - New options to run certain geoprocessing tools like Buffer, Spatial Join, Select, or Intersect as queries in databases that support these operations, which will result in improved performance.
I'm hoping this will also help me out a lot.
1. How long does that exact same join take in ArcMap using the Add Join tool: https://pro.arcgis.com/EN/PRO-APP/TOOL-REFERENCE/DATA-MANAGEMENT/add-join.htm? What about using the right-click > Joins and Relates > Join (you may need to use a stopwatch to get an estimate as you don't get Elapsed Time this way)?
Using the right click option is seemingly instantaneous, I tried to time it but it is probably a second or less. Unfortunately, when I tried the Add Join tool in ArcMap it gives me an error
The error doesn't make any sense (it's an Excel table, it has no OID) and also means I cannot fully replicate the process used in Pro. I know this ventures away from Pro but any thoughts as to why the error is coming up? Perhaps this is similar to the issue Pro is having? On the awesome side, ArcMap seems to have no issues with working with an Excel table. I may just have to create this particular map in ArcMap for now.
Don't you just love troubleshooting????
I just did a calculate geometry (X and Y) field calculator on a 900 row attribute table and it took 15 minutes. WTF. Even if you ignore the whole local vs. network and processing, it's all the mini loading times that destroy productivity. Professional users don't need a fancy ribbon and big 'graphicy' contextual menus, they need a sharp clean, reactive GUI where things are locked into place so you can use muscle memory and keystrokes to fly through work.
The software should instantaneously load all of the frequently used windows like other have mentioned (i.e. symbology, select by location etc. No load time, just load. Look at Autodesk software for inspiration. Such a clean and productive interface.
I do like the query builder for building definition queries ('includes the values...' drop down etc.).
ESRI should send a survey to Pro users getting them to rate all the aspects of the interface from 1-5. I'm pretty sure they would soon see what rocks and what sucks.
Peter- We are teaching with 2.4 this semester and finding serious performance issues over our network. So much so that we have students copy their data down to the local machine, do the work and then copy it back to the network for storage. Even the littlest things, like creating a new feature class, fail across the network. Connecting to a folder over the network is painfully slow. OMG. It almost seems like indexing is carried our every time I open the folder location. The weird thing is, imagery from our server draws very fast and performs well.
We're finding that doing operations off the local drive are reasonable. Haven't see the long local processing times you mention, although we are just getting in to other functions and operations like joins. We have brand new fast Dell workstations with Nvidia graphics processors and SSD drives, so maybe that makes a difference. Still, our network uses a 27 TB SSD cache drive, so it should be just fine.
This is almost a show stopper right now. If we didn't have good local machines with large hard drives we would be sunk.
Network performance appears to be a serious problem that ESRI is hopefully working on because it renders their software useless and erodes users trust. Don't really know how this network performance issue escaped the developers and quality control folks at ESRI. Baffling. I've been working with ESRI software for over 30 years and this problem is in line with some of the worst performance problems I've seen.
Bill
You may want to call tech support and see if you're experiencing BUG-000118068 ArcGIS Pro projects stored in the My Documents folder hosted on a network file share with an offline feature service takes up to 20 minutes to open.
Calculate field > enable undo, resulted in an order-of-magnitude increase in processing time on the same file, with an almost identical operation. "Enable undo" turned on took 24 minutes to run... and 32 seconds with "enable undo" turned off. What can be done so that "enable undo" becomes a usable option that isn't so expensive for efficiency?
Hmm, I just had the opposite experience.
Calculating a field with Enable Undo on completed in 6 seconds:
With Enable Undo off it took 15 seconds:
I can play with this some more, but more details may be needed...
Bob, are you working in a project with a number of maps/layouts?
If you were to open an Untitled Pro project and work with the same dataset, what do your performance numbers look like?
While it is expected for processing to take longer with Enable Undo on: Undo geoprocessing tools—ArcGIS Pro | ArcGIS Desktop
Performance and scalability
When geoprocessing tools are run in an edit session, performance will decrease compared to when the same tool is run outside an edit session. Similarly, scalability will decrease, as fewer features can be processed in an edit session compared to outside an edit session.
the example you're giving of 32 minutes doesn't seem right.
I just did another test
ArcGIS Pro 2.4.2
49,542 points in shapefile.
Calculating Long field.
Enable Undo on = 1 min 14 seconds
Enable Undo off = 47.45 seconds
Are you able to provide a project package that we could use to investigate the performance you're seeing?
Yes, the issue seems to occur with too many maps/layouts open in the same project.
Thanks, Bob Sas At this point, we can assume and hope that the work already done in ArcGIS Pro 2.5 will resolve the issue you included in the comment above. If you are able to share the project package, I can get it to the appropriate team as a real-world test case which can either validate the development work done, and/or may reveal areas for further optimization. Thank you!
Hi Bob Sas Would you be able to share the project package where you're seeing the long lag shown in the screenshot? We believe that what you're showing will be improved in ArcGIS Pro 2.5 with better handling of projects that contain multiple maps/layouts, but we can't be sure unless with test the case you're showing.
If possible, and if the package is small enough to email, could you send to kkramer@esri.com? If it is too large to email, send me a message and I can set up a file transfer site. Thank you!
Kory,
Can you expand on how 2.5 will improve project performance where we have many maps and layouts?
I am experiencing significant slow downs with my projects (which have grown over the past year). I have been working around the problem by using one project as a “working” project where I do all my editing and then housing all of my layouts that I export out as PDF’s or .jpgs in another separate (large) project. This way I can at least edit things efficiently although my “export” projects can take 3-5 minutes to load versus about 20-30 seconds for my editing projects (which contain one map with all the layers I need to edit).
I’ve also noticed that closing all layouts and maps in my “export” project is critical. If I leave anything open when I save and close the project can take 10+ minutes to load.
Its good to hear that ESRI is aware of the project size issue and is working on it.
Sean Hlousek
GIS Manager
1001 17th Street Suite 1250
Denver CO 80203
39°44’56.52”
104°59’36.43”
303-226-9516 (O)
303-565-0224 (M)
Attachments
Hey Sean! The improvements specifically cited here are in relation to geoprocessing performance in a project with many maps and layouts. Bob's screenshot shows exactly the kind of thing that can occur when there are a number of objects to update after geoprocessing has completed. So, you might see that the tool reports it completed in 27 seconds, which it did, but then it could take a long time for everything else in the project to sync up. I can't speak specifically to whether the export situation would be alleviated with the Pro 2.5 improvements, but if it doesn't, you can let us know.
Cheers
Specifically, as best I can detect, the slowness occurred because of an active layout consisting of a mapseries of 60 sheets with 3 dynamic maps and 15 fields of dynamic text per sheet. The issue was not actually because of undo edits in geoprocessing but in updating those edits into too many dynamic layout elements.
Thanks for the info, Bob. We'll take a look.