Submitted a PR to introduce pagination - I'm not 100% sure it will make a huge difference, it may require additional caching of group membership that is not currently performed. 

I also turned up https://issues.igniterealtime.org/browse/OF-1618 whilst doing this, it seems there is /some/ caching going on!

Oh, bother. Sorry, should read more carefully. In which case, it's much easier.

The code already fetches all admins/members, filtering and paging that should be relatively easy. However, as all members still need to be fetched from LDAP it may not be that much quicker. I'll try the simple improvements soon-ish, anway.

You're describing a slightly different problem than what I intended to be the subject of the discussion. We see issues on the 'edit group' page, where one single group has many members.

On the face of it, this may suffer from the same problem as https://igniterealtime.atlassian.net/browse/OF-1542#icft=OF-1542 - the GroupProvider offers a method

Collection<String> getGroupNames(int startIndex, int numResults);

which only retrieves some of the groups. The ListPager currently requires all of the "things" to operate properly.

However, I notice that group-summary.jsp starts with a call to GroupProvider.getGroupCount() which (every 5 minutes, anyway) iterates over all the LDAP groups, anyway. I'd expect the number of groups to be orders of magnitude less than the number of users. By caching the groups in LdapGroupProvider (not just the number of groups) it should be possible to achieve the desired affect - do you see any problems with this approach?