Problem/Motivation
This is responsible for 4.5M of memory usage when submitting the modules page.
Views::getApplicableViews() initializes view display plugins.
The Feed display plugin has the following code:
/**
* Overrides \Drupal\views\Plugin\views\display\DisplayPluginBase::initDisplay().
*/
public function initDisplay(ViewExecutable $view, array &$display, array &$options = NULL) {
parent::initDisplay($view, $display, $options);
// Set the default row style. Ideally this would be part of the option
// definition, but in this case it's dependent on the view's base table,
// which we don't know until init().
$row_plugins = Views::fetchPluginNames('row', $this->getType(), array($view->storage->get('base_table')));
$default_row_plugin = key($row_plugins);
if (empty($this->options['row']['type'])) {
$this->options['row']['type'] = $default_row_plugin;
}
}
This ends up invoking hook_views_data(), with a cold cache, which means 4.5M of memory usage as measured by xhprof.
Proposed resolution
@todo
Remaining tasks
@todo
User interface changes
@todo
API changes
Comments
Comment #1
catchLet's see what breaks if we just rip that out.
Comment #2
catchComment #3
catchComment #5
dawehnerSome work to get it passing.
Comment #7
dawehnerThere we go.
I guess it would be great if @catch could verify that this actually improves the memory situation
Comment #8
tim.plunkettCouldn't this also be moved inside the if() for the 99% case?
Comment #9
dawehnerSure
Comment #10
yesct commentedComment #11
catchWith no xhprof but writing out memory_get_peak_usage() from index.php:
Before:
After:
As you can see, there's approx 500kb less memory usage on the submit, but approx 4mb more on the subsequent page render.
As far as I can tell in xhprof, what this represents is the following:
1. In the router rebuild, we don't get the plugin definitions at all any more. However we rebuild the theme registry there, and that does.
2. When building the page, we get the row plugin definitions in the theme registry both times.
What this means is that if we only trigger the route rebuild and not the theme registry rebuild in the same request, then we'll see the improvement. So despite it not helping this scenario, I still think it's a good improvement.
Comment #12
catchWhile it doesn't improve the numbers here (because we still get row plugins), as a result of trying to unpick this issue I found #2497113: views_theme() gets 19 types of plugin definition, only needs five.
Comment #13
dawehnerSo now that this doesn't improve the actual numbers, should we keep the issue open?
Comment #14
catchI think it's good clean-up, but just clean-up at this point.
Comment #15
damiankloip commentedThis looks good to me, good cleanup!
Comment #18
catchComment #20
catchThis still improves performance, because views' route subscriber initializes views for the ones that actually have routes still.
Comment #21
catchPatch came back green.
Committed/pushed to 8.0.x, thanks!