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.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | panels-DRUPAL-5--2.plugin-cache.patch | 8.1 KB | sun |
Comments
Comment #1
sunThat 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.
Comment #2
sdboyer commentedYeah, 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?
Comment #3
sunI 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.
Comment #4
sdboyer commentedhttp://doxy.samboyer.org/panels2/panels_glossary.html
http://doxy.samboyer.org/panels2/panels_api_plugins.html
=)
Comment #5
smk-ka commentedConfirming 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.
Comment #6
sdboyer commentedThanks 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.
Comment #7
smk-ka commentedGood to know, I'm looking forward to test/review/profile...
Comment #8
sunAttached patch is what smk-ka and me are successfully using on a few sites. In short:
1) We are building a registry of all available plugins in panels_get_plugins(), and caching it in the database.
2) On regular panel outputs (rendering), the information, which plugins are available and which plugin lives where is retrieved from the cache.
3) Only on panel_edit* pages, the cache is rebuilt, so you get the proper/current plugin data. Since there is no unique entry point for those panels edit pages, but they are using the panels_get_PLUGINs() [note: plural] functions, we flush the cache when one of them is invoked.
4) Additionally, we are statically caching the results of panels_ct_get_types().
Let me add that those changes lead to a vast performance increase on our sites.
Comment #9
merlinofchaos commentedWith the release of Drupal 7, Drupal 5 is no longer supported.