Closed Bug 870226 Opened 7 years ago Closed 7 years ago
On debug builds it takes a very long time to display the search engines in the Awesomescreen after first load
Nightly 23.0a1 2013-04-08 HTC Desire (Android 2.2)/ Samsung Galaxy R (Andoird 2.3.4) Steps to reproduce: 1) Download the latest mozilla-central sources and make a debug build using these options in the mozconfig file: ac_add_options --enable-debug ac_add_options --disable-optimize 2) Install the build on the device and start it 3) After the content of about:home is loaded tap in the URL bar and enter a few letters Expected results: The suggestions to search using the available search engines are displayed Actual results: The view remains blank for up to 1 minute after about:home was loaded Note: The issue is also reproducible on the Smasung Galaxy Tab 2 (Android 4.1) but the delay is a lot less - a few seconds. I am unable to reproduce this with the official Nightly builds on any of the devices
Everything is going to be slow on a debug no-opt build. Are the search engines disproportionately slow compared to other Gecko operations in that build? How long does it take to load the first page, for example?
The time to load the first page is similar. The issue here is that it takes up to another 30+ seconds to 1 minute in the worst cases after Gecko:Ready to display the first page / the search engine suggestions.
I think this is expected behaviour then. Slow devices are going to be slow with debug no-opt builds. I've been using debug builds for development for a long time and they're always really slow compared to nightlies.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Understandable the debug builds will be slower then normal builds but what I am constantly seeing is debug builds being extremely slow and laggy for 30 sec+ after Gecko:Ready is sent. Since Robocop waits for Gecko:Ready before starting the test the first page loads/awesomescreen paints are really slow and this affects the tests and cause intermittent failures. The Tegra devices in particular are very slow devices. We should look into delaying blockForGeckoReady() until it the build starts to behave normally, maybe look into the events that cause the Settings entry in the Custom menu to be activated since it seems to be related.
You need to log in before you can comment on or make changes to this bug.