Contrib.social

Options Select Widget: High Memory usage

Open on Drupal.org →
Created on 24 January 2017, almost 8 years ago
Updated 20 February 2024, 9 months ago

Using the Options Select Widget for entity reference fields can have a huge impact on memory usage, especially when there are large numbers of referenced entities.
As an example, on one content type my memory usage is about 81.5MB per page load when I go to the node/add page when I use an Autocomplete widget for a field with a particularly large option list. That jumps up to 371.25MB when I switch over to the Option Select widget.

For my personal use case, I can just switch over to the Autocomplete for a work-around. However, this seems like an issue that needs to be addressed.
Looking at the source code, it looks like the full entity is getting loaded when generating the options list. 

  /**
   * {@inheritdoc}
   */
  public function formElement(FieldItemListInterface $items, $delta, array $element, array &$form, FormStateInterface $form_state) {
    $element = parent::formElement($items, $delta, $element, $form, $form_state);

    $element += array(
      '#type' => 'select',
      '#options' => $this->getOptions($items->getEntity()),
      '#default_value' => $this->getSelectedOptions($items),
      // Do not display a 'multiple' select box if there is only one option.
      '#multiple' => $this->multiple && count($this->options) > 1,
    );

    return $element;
  }

Maybe it be possible to improve performance by just loading the Entity Label instead?

🐛 Bug report
Status

Active

Version

11.0 🔥

Component
Field  →

Last updated about 11 hours ago

Created by

🇺🇸United States nplowman

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 9 months ago →
    🇩🇪Germany donquixote

    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.

  • Status changed to Active 9 months ago
  • Comment 9 months ago →
    🇩🇪Germany donquixote

    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.

  • Comment 9 months ago →
    🇩🇪Germany donquixote
  • Comment 9 months ago →
    🇩🇪Germany donquixote

    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.

  • Comment 9 months ago →
    🇩🇪Germany donquixote
  • Comment 9 months ago →
    🇳🇿New Zealand quietone

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

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024