If you define a set of pages, panel_mini, handlers... using hook_default_page_manager_pages, hook_default_page_manager_handlers, hook_default_panels_mini...
usually you have all the exports in a big include file or lot of small files that you load/include with your default hook functions.

The problem is that this file access is done many times everytime you use a panel, mini_panel or handler, affecting to performance and memory use.

The proposal is to use a drupal cache to cache this objects instead reading the definitions every time, this way you can use not only the default db cache but also memcached or cacherouter alternatives.

I attach a patch for ctools.install where I added the schema for cache_ctools tables and creation update function and other for include/export.inc where I use any existing configuration in cache (if any) but when you are in an admin path or cache was empty then you read always from the hook functions.

There could be some different options to this, as it could:
- use standard drupal cache or
- use always cache removing the directory path check
- add a configuration setting to define if using or not cache (or where)

CommentFileSizeAuthor
ctool_install_drupal_cache.patch1.04 KBjcmarco
export_drupal_cache.patch3.14 KBjcmarco

Comments

merlinofchaos’s picture

merlinofchaos commented

I'm not sure I particularly like that check for the admin/ path. Views does this same thing by forcing a cache clear when visiting the modules page, and providing an API function to clear the cache so that modules which do things that should clear this cache can and it seems to be pretty much sufficient. Also, when performing a menu_rebuild, functions that use these things could set a flag to force reading uncached data, perhaps.

merlinofchaos’s picture

merlinofchaos commented
Status: Needs review » Needs work
sdboyer’s picture

sdboyer commented
Status: Needs work » Closed (won't fix)

No. Firing queries has its own overhead, and the time to include the file (especially if you're running an opcode cache - and if you care about performance and you're not, don't even talk to me) is gonna be on par with or less than the query time. Memory usage will be exactly the same with an opcode cache, assuming the same final object is built. And, exports are about portability. Which is why we look to get them out of the database in the first place.

So, no.