Replacing a lot of chained tokens is heavy on performance and could lead to a max_execution_time error

Can you provide some more information in what level/token it exactly starts to loop and how? And a test for this would nice.

Sounds like it might be related to multiple nested tokens on the same field in a single text.

This indeed dramatically improves performance of replacing chained tokens. And it seems everything keeps working. Now all that is left is understand why.

Faced the same issue. Re-rolling patch from #6 against current 8.x-1.x

#9 Patch applied cleanly.

Finally found some time and motivation to look into this. Can reproduce the problem.

The basic problem is that we loop over tokens one by one *but* \Drupal::token()->findWithPrefix() works on all tokens and is not meant to be used in a loop, which is a bit tricky as we need to know if there are field tokens and for which field. So it looped over all tokens and each loop found all tokens for the same field. And if you have 2-3 such references then you get that nice exponential growth of nested calls.

I tried to address this at the root with two changes:

1. I'm filtering out all identified $field_tokens that are already in $replacements.
2. That alone won't prevent repeated calls on the nested levels because those don't have the $replacements yet as that is not shared between nested calls. So I check it to call the found tokens one-by one. There is a bit of overhead with that, but in my testing, it is clearly more efficient as we don't have to worry about multiple matches. Thought about even calling field_tokens() directly and skipping the hook over all token hooks + alter.

Additionally, I also noticed that we might be trying to load the same view display a lot and added a static cache for that and only attempt to load it if we need it. I suspect that will cause some issues with tests. Might drop the static cache again, would likely require a ton of fields that are rendered through the formatter to make that worth it and then you have different problems.

I think this will also help with metatag a bit, e.g. when you are using image + width/height tokens of an image field on a media reference of a node.

To test/reproduce, I simplified it a bit to use a media reference field on a media entity, with a reference to itself, so I can repeat as many "nested" fields as I want. And then the following script:

use Drupal\media\Entity\Media;

$media = Media::load(1);

$token_text = '
mid: [media:field_foo:entity:field_foo:entity:field_foo:entity:mid:value]
bundle: [media:field_foo:entity:field_foo:entity:field_foo:entity:bundle:target_id]
vid: [media:field_foo:entity:field_foo:entity:field_foo:entity:vid:value]
created: [media:field_foo:entity:field_foo:entity:field_foo:entity:created:value]
langcode: [media:field_foo:entity:field_foo:entity:field_foo:entity:langcode:value]
name: [media:field_foo:entity:field_foo:entity:field_foo:entity:name:value]
status: [media:field_foo:entity:field_foo:entity:field_foo:entity:status:value]
uuid: [media:field_foo:entity:field_foo:entity:field_foo:entity:name:value]
';

echo \Drupal::token()->replace($token_text, ['media' => $media]);

on HEAD, that takes 26s for me. With the patch, it's 0.2s and that's including the drupal bootstrap, measuring with "time drush scr foo.php" The example might be a bit extreme, but it's not too far off from those commerce use cases.

Thought so, dropping the static cache from that for now but keeping the function.

Also, forget the part about metatag, that would only apply when rendering multiple token for a single metatag.

Lets hope this doesn't introduce any regressions, really want to have this in a release.