catch’s picture

OK debugged the really, really high memory usage in #drupal with Damz and Berdir. Query logging and having xdebug enabled accounts for some of it.

However, with both of those disabled, and no APC, the menu rebuild still takes around 7MB of memory on my system just for itself (out of a total of 32MB).

andypost’s picture

my stats for D7 + all modules enables + devel (admin/build/modules) windows box (php 5.2.9-2 + apache 2.0.63)

eaccelerator enabled:
Memory used at: devel_boot()=0.27 MB, devel_shutdown()=6.67 MB, PHP peak usage=7.25 MB.

eaccelerator disabled:
Memory used at: devel_boot()=1.82 MB, devel_shutdown()=21.63 MB, PHP peak usage=22.25 MB.

with return; at menu_rebuild

eaccelerator enabled:
first run Memory used at: devel_boot()=1.64 MB, devel_shutdown()=18.57 MB, PHP peak usage=19.25 MB.
next run and others Memory used at: devel_boot()=0.26 MB, devel_shutdown()=2.86 MB, PHP peak usage=3.5 MB.

eaccelerator disabled:
Memory used at: devel_boot()=1.83 MB, devel_shutdown()=17.78 MB, PHP peak usage=18.25 MB.

As I see menu_rebuild() eats near 3-4M for own data

andypost’s picture

Here the screens of zend profiler (all core enabled + eaccelerator)

pm(*).png - normal d7 core

p(*).png - menu_rebuild() excluded

andypost’s picture

130.6 KB
55.53 KB
92.63 KB
31.14 KB

This with menu_rebuild() skip

andypost’s picture

113.95 KB
49.08 KB
84.67 KB
86.6 KB
84.73 KB
30.4 KB

Another series but without eaccelerator

andypost’s picture

107.92 KB

The most expensive menu_rebuild() because _menu_navigation_links_rebuild()

c960657’s picture

moshe weitzman’s picture

Status: Active » Fixed

We also changed menu_rebuild to do many smaller INSERT instead of one gigantic INSERT. Please reopen if there is a real outstanding issue.

Status: Fixed » Closed (fixed)

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