I have a taxonomy vocabulary with over 4000 terms, and I'm using hierarchical select to select a term on the node editing page. The HS is unbearably slow on my local installation; Selecting a single level in the HS element takes over 10 seconds.
I have actually two HS elements on the page: One for selecting a taxonomy term, and another one for selecting a menu item. Both the hierarchies have over 4000 items, as the menu is generated with Taxonomy Menu from the vocabulary. Only one is needed for each node; either the term or the menu item.
I've traced the code to find the problem, and I've found a few issues (some of them reported already):
When a new term is selected in the HS, the AJAX backend processes the whole node form. This seems like totally unnecessary overhead to me, and it's already reported here: http://drupal.org/node/578984 . I.e. when selecting a taxonomy term, HS runs the code for menu items. And vice versa. I suspect the same goes for all the submodules.
The hs_menu module goes through all the menus, and runs menu_tree_all_data() for each menu. This is called from "hs_menu_hierarchical_select_children". It also seems to call the function for _each_menu_item_ in the currectly selected menu item select element(I think).
And it does all of this _every_time_ I select a new _term_.
So, the problems:
- Touching one HS element processes them all (http://drupal.org/node/578984)
- The system goes through all menus, not just the one selected in the HS element. (I don't think there's an issue for this)
- menu_tree_all_data() is called repeatedly for a single menu (My patch takes care of this)
- menu_tree_all_data() is called at all... As far as I understand, we're just interested in the children of the parent passed as a parameter to hs_menu_hierarchical_select_children(). It would be much faster to to a database query to the menu table and filter by plid.
These issues run deeper than I have time to spend on this, so here's a quick-fix patch that adds CacheAPI caching and static caching to hs_menu.module:hs_menu_hierarchical_select_children(), speeding things up a little.
Related to issues http://drupal.org/node/370505 and http://drupal.org/node/544324 .
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 1349218-2.patch | 552 bytes | wim leers |
| #1 | hs_menu_performance_issues_caching_fix-1349218-1.patch | 1.11 KB | firebird |
Comments
Comment #1
firebird commentedComment #2
wim leersmenu_tree_all_data() already does the necessary caching. But I do see that in D7, menu_tree_all_data() now has a new, optional $max_depth parameter. So why don't we leverage that instead?
Please review.
Comment #3
Sneakyvv commented@Wim leers: I might be wrong (I didn't look into it thoroughly), but menu_tree_all_data caches the tree params not the actual menu. So menu_build_tree is still being called each time.
Anyhow, this issue is quite old, but I stumbled upon it because my node add/edit forms are slow. After profiling it with xdebug, I found that the heaviest component for the page was the (building of the) menu select, which is needed for assigning the node to a menu. Let alone the fact that loading the menu tree should really only happen on-the-fly when I actuallydo (re)assign the node to the menu, not on load, since I might not use it.
I use hs_menu so it should be less heavy since it should only show the root of a menu, and thus only load that root (and only the child items when a root item has been selected). The patch you propose would probably do that (no caching however), but I see no performance benefit from it. Possibly because it is still building the (full ?) tree.
However, I also noticed that the original reporter of this issue (@firebird), did create a module after posting this issue (and before you proposed the patch). That module, menuperformance, does give a significant performance boost. I have quite a large menu (about 6500 items) and I went from a load time, for the whole page, of 1300ms to 300ms, a 77% gain.
Just saying, so anyone else who's having this issue knows, ànd so you could look how that module's doing it (or yielding this module in favor of that one).
Comment #4
stefan.r commented@Sneakyvv I have added a link to menuperformance on the project page -- I assume the performance boost also applies to hs_menu?
Comment #5
goldThe menuperformance module made a significant difference for me. With the lack of movement and the recommendation on the project page I'm inclined to say this is not an issue any more.
Comment #6
david.hughesInteresting thread to follow - just here to report that you should take care if trying out menuperformance. See this issue: https://www.drupal.org/project/menuperformance/issues/3037315
Currently investigating.