Why is bean_reset() called during Bean::save() ?

Hey, nice work. I added bean-reset to clear the block caching (and other layers of drupal caching hell).

I'd really like to get rid of if necessary but I think it is necessary. The call to bean reset wasn't in the initial code.

This is likely related to this issue: https://drupal.org/node/20655511

I did some digging, here's an example of the issues you can expect while running with bean_reset() commented out: https://drupal.org/node/1786036, https://drupal.org/node/1850814

After looking over the code for bean_reset(), the only "slow" function call appears to be the menu_rebuild().

function bean_reset($skip_menu_rebuild = FALSE) {
  // Clear ctools cache.
  ctools_include('plugins');
  ctools_get_plugins_reset();
  cache_clear_all('plugins:bean:types', 'cache');
  cache_clear_all('ctools_plugin_files', 'cache', TRUE);

  // Invoke modules to clear their caches.
  foreach (module_implements('bean_cache_clear') as $module) {
    module_invoke($module, 'bean_cache_clear');
  }

  // Rebuild ctools plugin types and the menu.
  ctools_plugin_get_plugin_type_info(TRUE);
  if (!$skip_menu_rebuild) {
    menu_rebuild();
  }
}

ctools_include('plugins'); => runs a few includes, pretty fast
ctools_get_plugins_reset(); => runs drupal_static_reset on a few things, very fast
cache_clear_all('plugins:bean:types', 'cache'); => deletes cache entries, usually fast
cache_clear_all('ctools_plugin_files', 'cache', TRUE); => deletes cache entries, usually fast
module_invoke($module, 'bean_cache_clear'); => runs drupal_static_reset on a few items and deletes more cache entries, usually fast
ctools_plugin_get_plugin_type_info(TRUE); => Usually pretty fast

menu_rebuild(); => Slow even on an empty site.

The above is all speculation, but my guess is that if the dependence on menu_rebuild can be removed, bean_reset() will probably become fast enough to run on save (and then you wouldn't have any caching issues).

Based on #1850814: After creating a new bean type, cache clear is required to manage fields of a bean and #2065551: Performance with bean->save and menu_rebuild, it looks like the call to menu_rebuild() is essential for new bean types (as the code is currently written) in order to get the block/add/type page to work. It's also necessary for Field UI to attach all the field management elements. (see field_ui_menu for why this is necessary for new bean types).

It looks like because of the way the code is written, both new beans and new block types call the same function (bean_reset()), so removing it from bean_reset() is going to break the creation of bean types on the fly.

You likely don't notice these problems because enabling a module calls cache_clear anyways which rebuilds the menu anyways.

What would be nice as a solution I think is the following:

1. Add a parameter to bean_reset() in order to trigger clearing the menu (default: false)
2. Only trigger bean_reset(TRUE) from the BeanCustom plugin where it's needed to rebuild the menu

However, this still causes a problem for Features and such sortof: consider, if you've created 10 bean types and put them in a feature, then the menu cache gets cleared 11 times: once for each bean type and once for the module being enabled. It would be nice to add some method of preventing the menu cache from being cleared that can be used by Features in order to not destroy the cache (maybe giving BeanCustom::save() an additional parameter for whether or not to kill the menu?)

Edit: Alternatively, we could just remove the menu cache clearing completely and call it manually from the admin interface when needed.

I'm kindof an idiot for not looking further before I posted... there's already a flag on bean_reset() in 1.x and the admin UI page is already calling drupal_flush_all_caches(). With those in place, there's no real reason for the menu cache to ever be cleared by bean_reset() that I can find.

It sound like the menu doesn't need to be rebuilt when saving a bean. However, when updating/deleting/creating bean types, it does need a rebuild.

The fix to this issue then is to update the bean_reset() call in bean->save() to be "bean_reset(TRUE);"

This won't change anything when working with bean types, but solves the bean save slowness.

Attaching patch based on above.

I like that solution.