Minor optimization for RecipeRunner::processInstall()

foreach ($install->modules as $name) { // Disable configuration entity install but use the config directory from // the module. \Drupal::service('config.installer')->setSyncing(TRUE); … \Drupal::service('config.installer')->setSyncing(FALSE); }

Comments & Activities

Not all content is available!

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

Issue created by @wim leers
@wim-leers opened merge request.
Status changed to Needs review about 1 year ago1:06pm 9 November 2023
Comment about 1 year ago →
🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
Status changed to RTBC about 1 year ago11:21am 14 November 2023
Comment about 1 year ago →
🇧🇪Belgium borisson_ Mechelen, 🇧🇪
Seems easy enough and should increase performance. LGTM.
Status changed to Needs review 12 months ago4:00pm 28 November 2023
Comment 6 months ago →
🇺🇸United States thejimbirch Cape Cod, Massachusetts
Status changed to RTBC 2 months ago3:02pm 11 September 2024
Comment 2 months ago →
🇨🇦Canada b_sharpe
Though in my tests the performance impact is negligible, this makes sense and has no impact on functionality. RTBC
Status changed to Closed: outdated 2 months ago3:36pm 11 September 2024
Comment 2 months ago →
🇬🇧United Kingdom alexpott 🇪🇺🌍
There's definitely no real performance benefit here. Also looking at \Drupal\Core\Extension\ModuleInstaller::updateKernel() we already take care of sync status across rebuilds of the container due to module install.

However this code has been extensively refactored so recipes can be installed in batch operation so the approach is invalid and the MR does not apply to 11.x core or recipes fork.

In light of the batch refactor I do not think this is worth pursuing.

Minor optimization for RecipeRunner::processInstall()

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments & Activities