GeckoApp.onCreatePanelMenu is called from GeckoApp.initialize() for SDK >= 11 here: http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoApp.java#1432 GeckoApp.onCreatePanelMenu accounts for 8.2% (194ms) of startup on my Galaxy Nexus. We moved the call to initialize() for some reason in bug 886528. Maybe we went too far.

Might be worth just testing this: stuff it last in the background thread initializers, and fast-init it when loading the menu. Where's most of the time coming from? Looking up views by ID?

It calls BrowserApp.onCreateOptionsMenu, which takes most of it's time in GeckoMenuInflater.inflate -> GeckoMenuInflater.parseMenu

This just removes these calls. I still want to make sure that we invalidate the menu at some point, so I moved that into onMenuOpened. I also moved the event handlers into BrowserApp since they're not used by any one else (Ideally we'd move all this code into the menu code, but that's a bigger refactor).

Comment on attachment 8369744 [details] [diff] [review] Patch v1 I'd like you to test a few situations: * Make sure a menu item correctly toggles (Bookmark and Request Desktop, for example) * Test on Gingerbread, ICS and newer phones, since invalidateOptionsMenu is a 11+ API and menus worked differently before it.

backed out: https://hg.mozilla.org/integration/fx-team/rev/6d962d016eae

Grr. Forgot to test on a device with a software menu button. Or... didn't realize that they were different. Pushed this to try: https://tbpl.mozilla.org/?tree=Try&rev=dea89e3ff9c0

GeckoApp.onCreatePanelMenu is no longer in the startup profile.

Let this bake a few more days, but we should consider moving this to Aurora. It's still early in the cycle.

This might have caused regression bug 972327. Please convince me otherwise.

Nope. It almost certainly caused that.