| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | field system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | 7.15 release notes |
Issue Summary
field_sync_field_status() runs for each module enabled / installed.
It uses system_rebuild_module_data(), which means that the data for all modules needs to be rebuilt (and all of their info files reparsed).
This gets old really fast. On an install profile with 133 modules (Kickstart v2), it adds minutes to the profile install time.
Original issue
The call to system_rebuild_module_data() in field_sync_field_status() is unnecessary and slows down installation noticeably due to the cache rebuilding taking place.
You might see #1599146: field_modules_enabled() greatly slows down profile installs, especially with features modules included and #1574716: Avoid unnecessary cache rebuilds when creating and updating fields for earlier discussion.
Here I am trying out a suggestion by bojanz from those threads, which is to do something like this - new code in the if-block, old code in the else-block for clarity:
<?php
/**
* Refreshes the 'active' and 'storage_active' columns for fields.
*/
function field_sync_field_status() {
// Refresh the 'active' and 'storage_active' columns according to the current
// set of enabled modules.
//
// But don't run the full system_rebuild_module_data() during installation,
// as it is slow.
if (variable_get('install_task') != 'done') {
$modules = module_list(TRUE);
foreach ($modules as $module) {
field_associate_fields($module);
}
}
else {
$all_modules = system_rebuild_module_data();
$modules = array();
foreach ($all_modules as $module_name => $module) {
if ($module->status) {
$modules[] = $module_name;
field_associate_fields($module_name);
}
}
}
db_update('field_config')
->fields(array('active' => 0))
->condition('module', $modules, 'NOT IN')
->execute();
db_update('field_config')
->fields(array('storage_active' => 0))
->condition('storage_module', $modules, 'NOT IN')
->execute();
}
?>For our large install profile, we found that this was a good speed-up and did not cause any unexpected issues.
Comments
#1
Here is the patch version of that code snippet above.
#2
This will most likely need to be rolled against 8.x--setting to needs review to see what the test bot has to say.
#3
The last submitted patch, fields-remove-unnecessary-rebuild-1599306.patch, failed testing.
#4
This needs to be redone.
For all intended purposes,
field_sync_field_status()is just a very stupid and inefficient way of doing amodule_list(). At this point of the installation process, the module list has been properly rebuild, so there is absolutely no reason to rebuild it ourselves.So let's just replace all this by:
<?php$modules = module_list();
foreach ($modules as $module_name) {
field_associate_fields($module_name);
}
?>
... and move on with our lives :)
#5
Here's a patch that removes field_sync_field_status() completely.
I see no reason why that function should run on cache clear and cron, if it already runs each time a module is enabled and disabled. That covers it.
Maybe yched can point out something that I'm missing.
Alternatively, field_sync_field_status() can be modified to call module_list() instead of system_rebuild_module_data(), which will at least kill the big performance impact (imagine installing 133 modules like Kickstart v2 does. At the end, it reparses 133 info files, and regenerates all data. Ouch!).
#6
The last submitted patch, 1599306-field-sync-status.patch, failed testing.
#7
Okay, let's try and be conservative then. Keeping field_sync_field_status().
#8
Simpler.
Running this on Kickstart v2 reduced the number of calls to system_rebuild_module_data() from 149 to 9, which decreased the total number of function calls during install by 34.9%, and decreased the total CPU time by 30.4%.
#9
This makes total sense.
#10
Here's the D7 version for later.
#11
Nice find. Looks good to me.
#12
Wow, great find!
Committed and pushed to 8.x and 7.x. Thanks! A performance increase like this might make sense to mention in the release notes for 7.15, too.
#13
Added to CHANGELOG in http://drupalcode.org/project/drupal.git/blobdiff/9535c1d93b66a5048fc763...
#14
Automatically closed -- issue fixed for 2 weeks with no activity.