Loading the gecko libraries is significantly slower on native ui than it was on xul ui, because things are happening while libraries are being loaded. On my nexus S, that's 1300ms vs. 900ms. This means that the expected improvements from incremental decompression won't have as big an impact as we'd like it to have. When starting the browser itself, we do expect people to get to the main screen and a slight delay in gecko initialization is not going to hurt much from the user perspective. However, when opening an url from another application, the delay will be noticeable. But in this particular case, the user doesn't care e.g. that the awesomebar is responsive and with results. We thus don't need to initialize the awesomebar early when the target is to display a page straight away. I'm pretty sure there are other candidates for such a delay.
Mike, what's actually running you think we should get rid of? This seems pretty meta, could you please file individual bugs for each thing that should be avoided? Did bug 711184 help what you're seeing? Also, I don't think we're doing any work to initialize the awesome bar. Are you seeing it in some start-up profiling you're doing?
Summary: Delay most initialization when opening an url from an external application → [meta] Delay most initialization when opening an url from an external application
Just a general user observation that it takes forever to initialize $whatever before actually seeing a page load being initialized. Combined with the fact that Gecko initialization starts late...
You need to log in before you can comment on or make changes to this bug.