Make plugin loading more targeted during render calls
sdboyer - June 29, 2008 - 03:11
| Project: | Panels |
| Version: | 5.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
I've not entirely confirmed this, but I don't want to let it slip by in the event that I'm right, so I'm posting this now...
Currently, _all_ content types are retrieved by panels_load_plugins() during any given render call, regardless of which/how many content types are actually being used. I haven't run cachegrinds on this to get a sense of how significant the performance impact is, but it does mean that every additional content type you have will make for an incremental performance impact on _every single panels load_, regardless of which client module is being implemented. Note that I'm note referring to pane types; to clarify, every plugin declaration function will be processed.
#1
That sounds scary. However, I can't confirm this after inserting a bunch of var_dumps() into a content type provided by a custom module. The dumps only appeared on pages where the content type was actually used.
#2
Yeah, I definitely need to check into this some more. Whether or not those var_dump()s showed up will depend heavily on where you put them, though, because Panels has a gradated process that it goes through when loading plugins. Did you put the var_dump()s into the actual plugin declaration functions, or somewhere else in the plugins?
#3
I put one var_dump() on the first line of each function of the plugin. However, it's not completely clear what you mean by "plugin". IIRC, I tested this in a content_type and a relationship, both provided by a custom module.
#4
http://doxy.samboyer.org/panels2/panels_glossary.html
http://doxy.samboyer.org/panels2/panels_api_plugins.html
=)
#5
Confirming this is an issue, which is causing us major headaches right now. Panels currently doesn't scale at all, you probably won't note it with a plain Drupal/Panels installation, but with a growing number of modules that expose their own panels_include_directory hook (and implementations) it's getting really worse.
The main problem is that there is too few information passed to the loader functions
panels_get_content_type($content_type)et al., to load just a (read: one) specific include file and execute the requested hook. Instead, panels_get_plugins() is called, which in turn calls drupal_system_listing() over and over again, coming close to DOS'ing your own site.This will most likely require API changes to the panels_get_*() functions, for example passing the whole $pane object to have the required module / submodule properties available for targeted plugin loading.
#6
Thanks for following up here smk-ka - yes, this was precisely my fear. I'm going to look into this either today or tomorrow - I have some ideas about how to fix it, but it's probably going to take a few hours of working away at it to _really_ make the behavior right.
#7
Good to know, I'm looking forward to test/review/profile...