Why is ArcGIS Pro so slow?

[ClintonJenkins1]

I like ArcGIS Pro. It is clearly a step forward in many ways. But why is it so slow for what are very simple things that should be nearly instantaneous. For example, if I want to adjust the symbology of something, ever single step causes the program to whir and think for about ten seconds, even when the layer is turned off! What exactly does it have to think about when the layer is not even rendering?

Almost every action in the program seems to generate some unknown processing demand. I can understand if the map is updating or a tool is running, but it seems to be for everything. This really drags down productivity and leaves me frustrated. If it wasn´t for this, I´d probably start switching to Pro completely. With all these lags though, it is impossible.

None of the data are on the network. Windows 10 machine, 32GB ram, fast video card not even close to maxed out. Most data are on SSD drives. 

[FrankHanssen]

Like the other comments I also struggle with an extremely slow ArcGIS Pro working on local data doing rather simple operations. I have tried on two computers with the same result... VERY frustrating!

[Jessica-SaraWillett_Chapignac]

Same thing, trying to delete some elements in the database and it can take more than 4 minutes for only one layer !

[ChrisLope]

I'm having the same issue!  I found this thread when googling and  Jakub Sisak‌'s post inspired me to look at my layout. 

I am on a brand new laptop (Intel i5 1.9Ghz, 16Gb RAM, Discrete GPU with 8Gb RAM) and I am in the middle of "fixing" (e.g. remaking) all of my maps now that I have a little more knowledge of what I'm doing.

The map I'm working on now is very, very rudimentary compared to what a lot of y'all do.  Light Grey basemap, an office point layer with about 5,000 rows (but definition queried down to 139), and three polygon layers.  My entire project file is only like 46Mb.

While making the map yesterday, everything was working fantastically.  Then once I created and started working on the layout this morning, that's when stuff started crawling.  CPU was hitting 80% and GPU hitting 98% (100% of that in 3D, even though nothing in my ArcGIS map is 3D.)  As with the map, there's not a lot going on in the layout either.  I just ran a test to see if I could duplicate the issue and things seemed to be running without an issue, even after I reopened the layout and did some tweaks to the legend.  Here's a screenshot of my map so you can see the context.  This shouldn't tax desktop in the least.

But as soon as I edited the font size of the title, my laptop spun up like it was a jet taking off, haha.  70+% CPU and 99% GPU usage.

As long as that ONE SINGLE TITLE element was selected and active, my CPU and GPU were getting hammered.  Once I clicked off the title, back on to "whitespace", everything went back to pre "rocketship to the moon" levels, haha.

[MarcoBoeringa]

I do not want to challenge your real world problems, but your specs and screenshot clearly show this is not a high end laptop, nor even close to it, and unfortunately you also don't seem to have a dedicated GPU contrary to what you thought.

Most Intel processors have an integrated GPU, and the "Intel UHD Graphics 620" you show, is just such a one. This has far less performance than e.g. a dedicated NVidia GPU. The 8GB "Shared GPU memory" is just ordinary RAM, not dedicated GPU DDR5 OR 6, which means the GPU "eats" away at your RAM, leaving less memory for the OS and ArcGIS Pro to work with.

Also, the latest Intel mobile Core i5 processors are already above 4GHz at top speed, rather than the slow 1.9GHz (although that may be base frequency, not peak).

At least having a dedicated GPU should definitely help with Pro, although it is also definitely not a panacea for all performance issues with Pro, far from it unfortunately...

[H__AlexHuskey]

Marco: It's a given that horsepower helps with software, but the problems of Chris and Jakub call for an Esri SWAT team, not their evasions & excuses. I tried using ArcGIS Pro (via Citrix at enterprise scale) and it's so horribly slow that I've given up. ArcPro is supposed to be stepping toward robust, fast, capable Cloud performance and is anything but. One experienced Esri support person told me the reason ArcPro takes so long to open a project is that it's scanning for every GIS related file in the folder--but no reason why. There can be no  justifiable reason for bad user experience. Our layouts and titles and projects shouldn't require authors to be detectives. This software provider is in the dark ages of customer service and needs to get with the program. I want to make online maps that make location info intuitive for my users, not fuss with software problems. Why does Esri relegate users to a suggestion box where only minor enhancements are implemented, instead of the bedrock functionality of the whole mapping program?

[MarcoBoeringa]

Hi H.Alex,

I don't work for ESRI, I am a user like you. However, posting performance issues based on mediocre hardware, won't help clarifying the real problems. There is a lot more software out there, that won't properly run without at least a dedicated graphics card.

I am totally with you that an ESRI SWAT team hunting down and fixing bugs is direly needed...

In fact, I think one of the main issues is that ESRI's backlog of fixing true bugs or other issues is so huge, that they don't manage to catch up with it. As a result, users keep reporting the same issues time and again, which in turn leads to valuable resources in terms of man power dedicated to support and resolving issues being wasted (support analysts / software developers) . Each time a user needs to report an issue that is already known by ESRI, a support analyst - and the user / client - wastes his precious time, that could have been used to track down and report other issues.

This is a vicious circle, that can only be broken by drastic measures (e.g. automated testing, better quality control before shipping releases etc.).

In addition, I have always felt that beside a "SWAT" team, ESRI maybe should halt *all* new development on all their software for a period of e.g. 3-6 months, and put all of their developer resources behind an all out effort into fixing as many known issues / bugs as possible. This is super drastic measure, but I think almost inevitable given the current situation if ESRI really wants to ever be able to catch up with the problems.

This could help in shifting the severe imbalance between the amount of time and manpower going into dealing with recurring known issues, and real knew ones, and significantly lower the allover "technical debt" in terms of issues needing fixing, and shift the overall balance between time spend on known issues to a more sane level, freeing up valuable resources to invest in e.g. overall quality control before shipping and thereby significantly and durably reduce the overall quality deficit and amount of issues in released software. This issue of imbalance is almost like an ecological problem, where disturbing the natural balance, can shift an entire ecosystem to a new stable, but severely degraded, equilibrium with much less species diversity and ecological health. We need to get to a sane new "natural balance", away from the current sickly equilibrium I.M.O.

Unfortunately, this has been an seemingly almost perpetual issue with ESRI to some extent. It is sad, because I do think there is a lot of dedicated support analysts out there doing great work, but could spend their time way more efficiently and satisfactory if issues were fixed in timely, A.S.A.P., manner instead of left to linger for release after release in some cases.

[H__AlexHuskey]

Marco:

It's great to e-meet you as a kindred spirit trying to save the pioneer of computerized mapping from itself! I like your idea of stopping further development until strong action is taken to catch up with eternal defects. It's mind-blowing to read Esri sales literature touting new or planned features when we can hardly do our daily work with the current programs. Deploying a SWAT team would require a Steve Jobs of Esri to give the orders--is there one of those around? Here's what Apple veteran  Michael Hageloh wrote in Live from Cupertino: "Jobs believed the market might not articulate what it wants, but it “knows what it needs,” and provides guidance in the form of “unspoken clues": For example, he perceived consumers’ frustration with MP3 players—due to bad control functions and limited storage, among other flaws—as a broad need for an innovative alternative. The market did not ask for the iPod, but it “clearly needed it.”

The difference with Esri is that the market is yelling out what we need. There's also a chance that some of Esri's inaction is based in the Microsoft business model which perpetuates busywork & vendor lock-in, and hence fees for customer service & licensing income--they don't want mapping to be too easy or affordable!

[JulieLeslie]

Most of us get our computers from our employer and generally they are not highly spec'd. Always in the past you could run GIS software on it, with most functions working promptly and quickly. Only once you did a bit processing (say an intersect of 500,000 or so features) did you have to go for tea/lunch/go home for the night.

Yeah, my graphics card is not robust and I am not going to get another. It seems you need a high end gaming computer system to run ArcPro. 

[H__AlexHuskey]

Julie:

Yes it seems like someone’s in cahoots with the gaming computer makers! But even our servers can’t keep up, so it’s really a terrible software problem on Esri’s part. They’re emphasizing Cloud services but not paying attention to the obstacles along the way. The captive audience won’t always remain that way!

Sincerely,

Alex

H. Alexander Huskey

Engineering Technician

Alex_Huskey@xtoenergy.com<mailto:Alex_Huskey@xtoenergy.com>

303/349-6986 cell

Bakken Operations Map - XTO Staff Only<https://xto.maps.arcgis.com/apps/webappviewer/index.html?id=08480eaf0c8a449d9e8fc51d21933006>

Bakken Business Unit / ExxonMobil Unconventional

321 22nd Avenue East

Williston ND 58802

[DrewFlater]

Chris Lope Can you clarify if this is a typo

My entire project file is only like 46Mb.

If your project file (the actual .aprx file in your project folder) is 46mb there is something going on, that's actually a huge project file. My aprx with many maps, layers, layouts, etc are usually under 1mb, sometimes only 100kb. I'm guessing this was a typo, maybe you mean the project folder is 46mb, or maybe the aprx is 46kb? 

If your aprx is 46mb it is likely your project file has become inflated with storage of something (map graphics? huge geoprocessing history?), which might explain performance problems.