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
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
Comment #3
catchDraft 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.