Improve responsiveness of commonly used GP tools e.g. Select by Attributes

[philippenn]

It is a common experience in ArcGIS Pro 2.x (including 2.9) to wonder why basic GP tasks such as Select by Attribute can take several/many seconds to load. Understanding that these things may be lazily loaded, could there be a configuration option to load on startup (preferably in a background thread) any user-defined commonly used tools?

Thanks!

[LindsayRaabe_FPCWA]

I find it annoying when the first time I click in the Command Search box at the top of Pro that it thinks about loading all the tools for a while before working. Surely this can happen after project open in the background before someone accesses the search function.

[DanMakridakis]

The slow performance of ArcGIS Pro is why I can never switch over for my daily tasks. It's insane how every little function takes a multiple of 2-3+ the time to run. Things that were never an issue in ArcMap are now painful. Even models that I built in ArcMap take twice the time to run in Pro. And don't get me started on trying to use model builder in Pro and waiting for it to process every little click. For cartography and map design, Pro is hands down superior, for everything else it is too painfully slow to waste my time using. And this isn't coming for someone not open to change, I love new tech, so I try and try and try to give it a chance and it just can't deliver.

[RogerCarribine]

This. This has been a huge impediment for adopting Pro\UN at one of our customer sites. They work with a lot of non-spatial records and the Select by Attributes tool is unusable in its current form. I'm not aware of another way to select table data beyond a custom solution. A managed/c# version of this tool is sorely needed. +1. 

[KoryKramer]

@philippenn Thank you for submitting this idea. You specifically mention Select By Attributes in the idea's title, and that has come up again in the comment by @RogerCarribine. 

There has been internal discussion around this concept before and I want to offer some considerations for discussion here when thinking about the problem and proposed solution.

1. Given that functional areas take some time to load, the current design, as you already noted in your description, is to wait until something is needed to load it. If we pre-load a functional area (or a user-selected list of X things) at startup , the user will wait anyway since startup will be slower by the same cumulative amount, and will be every time, even if they don't use the functionality every time.  A small “cold hit” that occurs only when someone uses a functional area for the first time, seems better than inflicting the hit on all users every startup; or even the same user who selected X things to pre-load - you would take that hit every time you start a project even if during your working session you use 2 of 10 pre-loaded things.

2. Time is only one factor.  Loading functional areas also consumes resources leaving less left over for other functional areas, and less resources available can also lead to performance degradation. This would be a reason to not pre-load a number of things that may not be used.

Again, just putting these points of consideration forth to generate discussion and solicit additional feedback.

Now, given some of the specifics around Select by Attributes, Philip, you mentioned that it can take several/many seconds to load and Roger, you note that it is unusable. Would you be willing to take a look at your specific project setups with me/share project packages that demonstrate exceptionally long load times? In testing a project that I have here, I did see an initial load time of 10 seconds, and subsequent times did not exhibit a delay. We'd be interested in looking at your projects and experiences specifically. Does it make any difference how many maps/layouts/tables that you have open, or you see the same delay with only a single view open? Please ping me if you're interested in sharing a specific example with us (kkramer@esri.com). Thanks!

[philippenn]

@RogerCarribine met with Kory on Friday to go over Select By Attributes and it seems like it was rewritten at >2.8 & is now a couple of seconds to bring up, which is fantastic news.

[KoryKramer]

We looked into the issue that was brought up by Philip and Roger through this issue and the conclusion is that the lag they were both reporting was when opening Select by Attributes in ArcGIS Pro 2.6.x. The performance has been dramatically improved through dedicated work in Pro 2.8 and 2.9 and as verified by both of them is no longer an issue in Pro 2.9.

As stated in the ArcGIS Ideas pre-submission considerations while performance issues are not prohibited from being submitted, they typically don't make the best ideas for a number of reasons.