Select to view content in your preferred language

ArcGIS Pro 3.3 performance

17361
36
05-15-2024 09:30 AM
HollyTorpey_LSA
Frequent Contributor

Is anyone else noticing any performance issues in Pro 3.3? We are, but I'm trying to figure out if it's a Pro update issue or something in our network/system configuration (or a combination of the two). Would especially love to hear from others who have updated to Pro 3.3 on a multi-session virtual desktop where users use Pro to work with data stored on cloud-based fileshares.

Thanks in advance! 

- Holly
36 Replies
George_Thompson
Esri Notable Contributor

Based on that specific case, I would work with technical support and see if this is a defect or not. Especially since it seems specific to SDO_Geometry.

--- George T.
0 Kudos
waterschapVallei_en_Veluwe
Occasional Contributor

I was already doing that, but no results so far.

0 Kudos
waterschapVallei_en_Veluwe
Occasional Contributor

Last update: it looks that is has to do with many relationship classes! I can reproduce the problem also with sde.ST_GEOMETRY storage based feature classes. If I do an Attribute Table of several feature classes in een Enterprise Geodatabase (Oracle) and as soon as the table tabs are displayed, I quickly open all these tabs and then it hangs. 

0 Kudos
Aaron
by
Occasional Contributor

Swinging back around to this... no change with 3.6: "CSharedQueue Stall timeout". Anyone notice and changes, better or worse?

0 Kudos
waterschapVallei_en_Veluwe
Occasional Contributor

Last statement about this problem that it has to do with too many relationship classes. ArcGIS Pro 3.5 and 3.6 cannot handle that. Esri can reproduce it and it is register as BUG-000181321 !

Aaron
by
Occasional Contributor

I only have file geodatabase connections, no relationship classes. It is definitely a performance issue with ArcGIS Pro. You can watch the logs in the Diagnostic Monitor at how inefficient it is. The most basic of examples: why does it redraw a legend with I am only viewing a map? Why does it open and close the gdb connection when simply selecting the layer in the Contents pane? I know there are reasons, but it seems like poor dev and is very disappointing. 

It's like Pro was developed in a utopian lab, using a local user with full admin rights, all data on the local machine or LAN, in a perfect environment, with minimal concern for the real-world conditions in 2026 (maybe even 2022).

/rant-off

HaydenWelch
MVP Regular Contributor

It's insane how amazingly slow database connections are. I can spool up a SQLite database and handle ~50k transactions/sec, but loading a table with 500 rows can take upwards of 5 seconds with a file database.

Don't even get me started on Arcade. They absolutely shouldn't have published that until they worked out the performance issues. It's so tantalizing for people and I always end up finding out that they've totally borked their database (~0.25 transactions/sec) because they added some arcade triggers to a table.

I have a Python toolbox that da.Walks out fileGDB template (~115 tables) and even on a local nvme drive with GB/s read speeds, it takes over a second to load. That's in headless too. The same code running in Pro takes 10+ seconds.

speed.png

0 Kudos