The compat group contained 10,000 member Resources. After clicking the Update Membership button on the Inventory>Members subtab, I waited a few minutes for the modal to finish drawing but it never did, so I eventually clicked the close icon at the upper right corner of the modal to close it.
For a group with 1,000 members, the modal takes about 6 seconds to load, so you would think a 10,000 member group would take around 60 seconds. I thought I waited that long but perhaps not.
Users will usually probably use dynagroups to create and update large groups, rather than using the group create/update wizards. That said, the poor performance for the selector component is a result of the fact that it loads the entire set of available and assigned items into memory (i.e. the data is not paged) in order to allow moving of items back and forth between the two sets purely on the client side. There are a couple things we could do to make this better: 1) redesign the selector widget, so it does not need to preload all of the data. this would not be trivial, and might require totally redesigning the GUI for the widget. 2) make sure to only fetch a lightweight version of the items in the lists. For example, for Resources, we could get by with just the id, name, ancestry, and type fields, but we are currently fetching many other fields.
The selector component now limits the number of available items it loads to a maximum of 100, but it still always loads the entire set of assigned items.
Closing this given the limiting approach. Further work here should be initiated by problems due to the latest approach. Filters should be added, if missing, to selectors that can't fit a reasonable set into the selector window.