Options Select Widget: High Memory usage

This is by design, in order to get the translated label of an entity we need to load the full entity object. And it's also the reason why the autocomplete widget exists :)

It is generally not needed to load all entities into memory at once.
To get a translated title while saving memory, we can/could/should load and "forget" the entities one by one.

We could also cache individual translated entity labels, and complete option lists.
(This needs cache metadata to deliver different filtered option lists based on user permissions.)

I don't see a "reopen" button here, but it would be appropriate.

Actually I _can_ reopen it!
The only case when we should close it is if we decide to open a new issue, or find one.

And it's also the reason why the autocomplete widget exists :)

I was going to switch a lot of widgets to autocomplete on a big site I work on.
Unfortunately this can come with some usability limitations.

Currently we use https://www.drupal.org/project/slim_select → which works for select widgets but not autocomplete widgets, because it does all the magic on client side.
I can imagine a similar widget could be created for autocomplete, but I have not found one yet.
Also, having the full option list on client side will make the UI more snappy as it avoids the need for ajax requests.

There is a middle ground of ~250 options, where we want a select list with optimized loading, rather than repeated autocomplete ajax requests. E.g. a country dropdown could have this order of magnitude of options.

This is on Version 8.9.x which is End of Life. Moving to 11.x

We have Options Select widgets with thousands of options. We use https://www.drupal.org/project/improved_multi_select → .

Autocomplete has major UX issues, the main one being: If the end user does not exactly know what to look for, he/she will have great trouble finding the option with autocomplete.

For us the memory usage is less of an issue than the loading times. We have pages with loading times >20 sec, just because of the Options Select, which are the same >99% of the time, compared to the previous form load. Also, our options will never be translated and will be the same for all users.

Another use case is that we do have thousands of entities, but only require a subset for a specific for. AFAIK there is no way to filter the options in a Options Select widget before they are all loaded: One has to wait until are all loaded and then can remove - in our case 80% of the - options using a widget hook.

I do understand the reasoning behind loading the full entities, but for our use cases it is just too much overhead, and there is no way to alter the behavior - except patching Core maybe.