Problem/Motivation

Closely related to #3572625: Calling $entity->getTranslatedField() results in an entity-sized memory leak but don't have a viable approach yet so opening in its own issue to avoid making that one even more complicated.

ItemList objects have a similar circular reference/memory leak issue to the $entity->fields property.

Each list item is a typed data object, which has a reference to the ItemList as the parent.

The ItemList itself will have a reference to the entity as the parent if it's a FieldItemList.

From looking in xhprof creating ItemList objects adds a lot to peak memory, even with #3572625: Calling $entity->getTranslatedField() results in an entity-sized memory leak applied - about 50% of the remaining memory leak as far as I can tell.

Going to push a draft MR here, but I think the approach in that MR is probably a dead end due to bc.

In that MR I'm trying to store the raw values in ItemList::list and translate them to/from typed data when possible. This isn't impossible, but several subclasses interact directly with ItemList::list, so changing what's in there can blow up.

I think we need a way for $item->list to still be an array of typed data objects as far as all calling code is concerned, might need property hooks for that.

Then we can either always create the typed data on the fly, or keep an array of weak references and swap things in and out of there.

FieldItem objects implement __set() etc. so we also need to make sure anything like that ends up back on the parent item list, since they have the parent and typed data has the $notify concept etc. that ought to be possible or potentially built in anyway.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3573982

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

catch created an issue. See original summary.

catch’s picture

Status: Active » Needs work

Draft MR is up but see discussion above, pretty sure it'll need a completely different implementation, but it shows where I think the problem is.