RecipeConfigurator::getIncludedRecipe() should statically cache recipe objects to avoid performance problems

This something that should have some test coverage? Or a follow up for recipe performance tests?

@alexpott and I discussed that and we feel that it does not because it’s completely internal refactoring, and it’s not clear how we would go about testing this anyway.

Marking as RTBC. There is a considerable difference with the patch applied.

Starting a site with the Minimal profile and then applying Drupal CMS Starter recipe.

ddev drush si minimal -y
then
ddev recipe-apply recipes/drupal_cms_starter

With patch -> 51s, 52s, 53,
Without -> 1m 28s, 1m 27s, 1m 29s

==============

I ran a second test, and drush site:install with the standard recipe and it was a second faster also.

ddev drush si core/recipes/dtandard -y

With patch -> 9s, 8s,8s
Without -> 10s,10s,9s

Committed and cherry picked back to 10.4.x

Looks like this broke HEAD of 10.5.x: https://git.drupalcode.org/project/drupal/-/pipelines/343235

In an unrelated MR elsewhere I'm also consistently hitting the exact same error

In InputConfigurator.php line 137:
                                                           
  Input values cannot be changed once they have been set.  
                                                           

recipe [-i|--input INPUT] [--] <path>

in both core/tests/Drupal/FunctionalTests/Core/Recipe/CoreRecipesTest.php and core/tests/Drupal/FunctionalTests/Core/Recipe/StandardRecipeTest.php.

Didn't check but I can imagine the same thing happening in 10.4.x?

Doh 10.4.x and 10.5.x have a change that 11.0.x does not. My bad. Fixed in a quick follow commit.

Committed and pushed e2a92ae2480 to 10.5.x and dd90bb9095a to 10.4.x. Thanks @spokje!

Automatically closed - issue fixed for 2 weeks with no activity.