Panelizer implements hook_admin_paths(), which is run everywhere and all the time, and hook_default_page_manager_handlers(), which is run for page manager controlled pages, and delegates this to all plugins. This will fetch all available plugins by using ctools_plugin_load_includes(), and that function only caches when you request a particular file.
This results in some disk IO and unnecessary cache writes, which is not very good for performance.
I don't know a good solution for this, but here are some ideas:
A) Change ctools_plugin_load_includes in CTools so that it caches even if you don't specify a file that should be loaded. This will impact various administration UI:s, since that would require a cache purge before any change is picked up. We could potentially add a parameter to the function, $bypass_cache or similar, if we want to bypass the cache for admin tasks, but this would still be a fair amount of re factoring to get that in everywhere it's used. If we want to go this route we should obviously move this to CTools.
B) Put a cache layer inside of panelizer. This will fix the problems, but it will also result in duplicate cache entries for the same thing, and CTools is meant to handle this thing already, but it will solve the immediate problem.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | panelizer-n1719090-2.patch | 418 bytes | damienmckenna |
Comments
Comment #1
merlinofchaos commentedA) isn't going to happen; that system is designed that way to ensure that we don't have dirty caches.
B) can potentially be alleviated just by turning on caching for panelizer entity plugins. Maybe you can give that a try? It's a simple flag in hook_ctools_plugin_type I think.
This isn't really a bug.
Comment #2
damienmckenna@merlinofchaos: Did you mean that panelizer_ctools_plugin_type() should be changed so that 'cache' is set to TRUE?
Comment #3
mglamanContext does this.
However git blame doesn't lead to a useful commit as to why/ticket :/. However, given what Context is used for I imagine this might be a useful patch. I'll try to keep testing and do some benchmarking.
Comment #5
damienmckennaCommitted.
Comment #7
damienmckennaHad to roll this back, it was causing problems.
Comment #9
joelpittetWhat kind of problems?
Comment #10
damienmckenna@joelpittet: Various menu lists were not reloaded after actions were performed; it probably just needs some drupal_static_reset() calls placed in appropriate locations, but it was too unstable as-is.
Comment #11
joelpittetAh, that is always overlooked (it seems and by me)
Comment #12
damienmckenna