The best time to register for DrupalCon Dublin is now. Earlybird discounts end July 29.
Splitting from http://drupal.org/node/497118#comment-1730752
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).
my stats for D7 + all modules enables + devel (admin/build/modules) windows box (php 5.2.9-2 + apache 2.0.63)
Memory used at: devel_boot()=0.27 MB, devel_shutdown()=6.67 MB, PHP peak usage=7.25 MB.
Memory used at: devel_boot()=1.82 MB, devel_shutdown()=21.63 MB, PHP peak usage=22.25 MB.
with return; at menu_rebuild
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.
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
Here the screens of zend profiler (all core enabled + eaccelerator)
pm(*).png - normal d7 core
p(*).png - menu_rebuild() excluded
This with menu_rebuild() skip
Another series but without eaccelerator
The most expensive menu_rebuild() because _menu_navigation_links_rebuild()
This may be fixed by #550124: Remove prepared statement caching or #496500: Remove global placeholder counter.
We also changed menu_rebuild to do many smaller INSERT instead of one gigantic INSERT. Please reopen if there is a real outstanding issue.
Automatically closed -- issue fixed for 2 weeks with no activity.
Drupal is a registered trademark of Dries Buytaert.