Pressflow has an alternate implementation of the menu system which allows a lot of it to be stored in APC. There's not a lot we can do in D7 to make the menu system properly pluggable, but seems like variable_get('menu_inc') would at least allow for things like that to happen without a core patch.

CommentFileSizeAuthor
menu_inc.patch860 bytescatch

Comments

Crell’s picture

Must we continue the "swappable include file" approach? There are so many better ways to make systems pluggable.

Granted, we may not be able to sneak much more than that into Drupal 7, but we really should be discouraging it.

catch’s picture

Status: Active » Needs review

I'd rather pluggable includes than core hacks, this also allows implementations to be tried out in contrib, which can be incorporated in cleaner pluggable systems in D8, like the numerous D6 caching back ends should be in D7. Variable includes were broken for months by the registry, then plugins didn't materialize, and we're now left with a mixture of one-off interfaces, some better than others, plus still variable includes for thing which didn't get converted before the registry revert. It's too late to fix any of that, so we should just make the best of what systems we have.

Several performance issues with the D6 menu system weren't found until relatively late in the D7 release cycle (access callbacks - especially when in combination with dynamic tabs, menu_rebuild()) - mainly of them only after Drupal.org moved to D6 which was months after release, some still have outstanding issues in the queue. Being able to test modifications easily might also make backports from D8 easier.

There are also issues like #643984: Cache menu_get_item() which only have a minimal positive impact for sites with a db caching backend (if at all) but quite a lot if using apc / memcache - which is likely to be an increasing number of sites as those get easier to implement, and more high-performance sites move to Drupal. The easier that code is to stick into contributed projects rather than custom hacks the better, especially if there's changes which end up being a net-loss for smaller sites (which I don't think that one is, but something like caching individual paths would be, which is why we just made path.inc swappable in #320132: Make path.inc swappable.

joshk’s picture

I'd rather pluggable includes than core hacks, this also allows implementations to be tried out in contrib, which can be incorporated in cleaner pluggable systems in D8, like the numerous D6 caching back ends should be in D7.

+1M for that. Swapping inc files may not the most svelt way to handle this — I'm sure there's a better architecture possible w/OOP or the like — but it works and feeds a the innovation cycle.

Crell’s picture

Status: Needs review » Reviewed & tested by the community

Sigh. I can't see us being able to do more than this at this stage for D7. Let's make undoing this a priority for D8.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Committed to HEAD. Thanks!

moshe weitzman’s picture

I could swear that back in the earliest versions of multi-site you could add a sites/all/includes and override files in includes folder that way. This was a sort of hush hush feature, that was not supported or encouraged. Seems like a good idea to me though.

Status: Fixed » Closed (fixed)
Issue tags: -Performance

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