Right now, calling view::delete always calls both cache_clear_all and menu_rebuild. That's perfectly ok to do in the UI, but when it hurts performance a lot when run in a batch: each delete will rebuild the menu, when one at the end of the batch, done by the caller, should be enough.

Attached patch (which should apply cleanly against 2.x-dev and with a small offset to 3.x-dev) adds a $clear parameter to view::delete, defaulting to TRUE. The situation should thus be the same for the outside world, but for example Features would be able to set it to false when mass reverting its default views, and call menu_rebuild after its loop.

Comments

DeFr’s picture

Attachment got lost somehow, trying again.

dawehner’s picture

Looks fine.

But why do you remove "In Drupal 5.0 and later this clears the page cache only."

This comment could still be there.

DeFr’s picture

In fact, I've updated it to "this flushes the block and page caches only", because while Drupal 5 only flushed the page cache when cache_clear_all was called, both D6 and D7 flush the page cache and the block cache that was introduced in D6. An accurate updated description would thus have been "In Drupal 6.0 and later, this clears the page and block cache only", but that looked a bit long.

I can reroll the patch with whatever wording you like best :-)

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

No, i just wondered.

Manual testing with a dsm message, worked fine.

merlinofchaos’s picture

Status: Reviewed & tested by the community » Fixed

Committed to all branches. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.