RegistryReader has bad performance on sites with a lot of users

Collections call view @@qsOptions for the query field options. That view is defined in plone.app.content, but it delegates all work to QuerystringRegistryReader in plone.app.querystring. Registry reader "simply" dumps configuration for all queryable fields and operations (both enabled and disabled), including all distinct values for related vocabularies. For sites with a lot of editors, vocabulary for Creator field may become large (and all values are twice in the resulting JSON, once for all indexes and once for sortable indexes). Yet, if the sites is using LDAP (tested only with LDAPUserFolder), rendering @@qsOptions requires fetching full name for all users, who have created content in the site. With some bad luck with the current LDAPUserFolder caches, this may choke a single instance site for a while.

I don't see any obvious fix for this. Comments and ideas are welcome.

Start at the @@qsOptions view in plone.app.content and follow its delegation to QuerystringRegistryReader in plone.app.querystring. Inspect how Creator and related vocabulary values are collected and serialized, then reproduce the LDAPUserFolder case with a large user set. Done would require an agreed fix and evidence that rendering no longer triggers excessive user lookups.