top sites takes almost 3 seconds to load content

VERIFIED FIXED in Firefox 13

Status

()

Firefox for Android
General
P2
normal
VERIFIED FIXED
5 years ago
9 months ago

People

(Reporter: dietrich, Assigned: lucasr)

Tracking

unspecified
Firefox 14
ARM
Android
Points:
---

Firefox Tracking Flags

(firefox13 fixed, firefox14 verified, firefox15 verified, blocking-fennec1.0 beta+)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
start cold
open a new tab

the Top Sites content area is blank white for up to 3 seconds.

opening warm shows a visible delay also, but not as bad, less than 1 second.
What buildid? This should be fixed by bug 725914
(Reporter)

Comment 2

5 years ago
How do I find buildid on native Fennec?
place about:buildconfig in the url
(Reporter)

Comment 4

5 years ago
built from http://hg.mozilla.org/mozilla-central/rev/5e756e59a794
That build has bug 725914 in it. We'll need to know the type of device and the size of your browser.db file. You should be able to "Move to SDCard" in Android > Settings > Applications > Nightly to do the move. Then you can pull off the DB.

Naoki might have an add-on to give a rough estimate of the DB size too.
Assignee: nobody → lucasr.at.mozilla
Keywords: fennecnative-betablocker
Priority: -- → P2
The simplest way to check db size is to open the Android settings > Applicaitons > Manage Applications > find Nightly and select it > press move to sdcard > go back to your home screen and launch Nightly. Then attach your phone to your computer as a storage device. check /Android/data/org.mozilla.fennec/files/mozilla/$profile-name.
(Reporter)

Comment 7

5 years ago
Nexus S didn't have it there. It has no removable storage. It had a "move to usb storage" option, which moved the data to http://cl.ly/3225322t333Z3M3i0I23.

Looks like some secure storage option maybe?
blocking-fennec1.0: --- → beta+
Status: NEW → ASSIGNED

Comment 8

5 years ago
Mark, Lucas can we help Dietrich extract his database size and figure out what's going on here?
(In reply to JP Rosevear [:jpr] from comment #8)
> Mark, Lucas can we help Dietrich extract his database size and figure out
> what's going on here?

While we try to do that... Dietrich, can you make a video of this happening? It might be useful to see what aspects of the UI are loading slowly.
Also - can we reproduce this on other Nexus S phones, or is it specific to Dietrich's profile?
Could be fixed by bug 735660 too.
(Assignee)

Comment 12

5 years ago
As Mark mentioned, I just found out yesterday that the perf improvements on DB were not being used at all. This means that even though Dietrich reproduce this bug on a build with my patches, the code that I added was simply not being used.

So, hopefully, once my patch for bug 735660 reaches Nightly, this bug will actually be fixed.
(Assignee)

Comment 13

5 years ago
I think the most outcome for this bug should be a talos test for the awesomebar filter function. This way we can have a better picture of what kind of performance we have on a history table with a few thousand entries.
(Assignee)

Comment 14

5 years ago
Created attachment 606595 [details] [diff] [review]
(1/3) Fix content provider registration in ContentProviderTest
Attachment #606595 - Flags: review?(gbrown)
(Assignee)

Comment 15

5 years ago
Created attachment 606596 [details] [diff] [review]
(2/3) Ensure test query arg on all ContentProvider operations
Attachment #606596 - Flags: review?(gbrown)
(Assignee)

Comment 16

5 years ago
Created attachment 606597 [details] [diff] [review]
(3/3) Add Talos test for AwesomeBar frecency filter
Attachment #606597 - Flags: review?(gbrown)
(Assignee)

Comment 17

5 years ago
These patches add a talos test for our awesomebar filter query. It adds 10k rows to history then runs the query with a known value. This should allow us to spot regressions and to track awesomebar DB performance from now on.

Updated

5 years ago
Attachment #606595 - Flags: review?(gbrown) → review+

Updated

5 years ago
Attachment #606596 - Flags: review?(gbrown) → review+
Comment on attachment 606597 [details] [diff] [review]
(3/3) Add Talos test for AwesomeBar frecency filter

This test looks good to me but I want to get Joel's input since I am not as familiar with Talos. 

I think we want the new test listed in the Talos section of robocop.ini and commented out, like testPan and testCheck. Joel, is that right?

I am seeing run times for testBrowserProviderPerf of about 180 seconds -- is that reasonable for a Talos test?
Attachment #606597 - Flags: feedback?(jmaher)
Comment on attachment 606597 [details] [diff] [review]
(3/3) Add Talos test for AwesomeBar frecency filter

Review of attachment 606597 [details] [diff] [review]:
-----------------------------------------------------------------

there is no UI interaction?  Does this need to be a robocop based test?  

180 seconds is not a big deal.  It is longer, but we have a lot of tests which are much longer.  Do you want to measure the time, or another factor?  How stable is the number over 10 runs?

::: mobile/android/base/tests/robocop.ini
@@ +13,5 @@
>  [testPasswordProvider]
>  [testPasswordEncrypt]
>  [testFormHistory]
>  [testBrowserProvider]
> +[testBrowserProviderPerf]

this is a talos test, please put in the section below as :gbrown mentioned.
Attachment #606597 - Flags: feedback?(jmaher) → feedback+

Updated

5 years ago
Blocks: 721731
(In reply to Joel Maher (:jmaher) from comment #19)
> 180 seconds is not a big deal.  It is longer, but we have a lot of tests
> which are much longer.  Do you want to measure the time, or another factor? 
> How stable is the number over 10 runs?

Most of the 180 second run-time is spent inserting history entries; after that is set up, the test measures and reports only the time for a filter operation, which is relatively quick: For 3 runs I got 273, 264, 269 ms.
great, those are fairly consistent.  The more runs the better, but at 3 minutes+/run, this could take a long time if we do 10 iterations.  Will 5 data points averaged out be good for reporting?
(Assignee)

Comment 22

5 years ago
(In reply to Joel Maher (:jmaher) from comment #21)
> great, those are fairly consistent.  The more runs the better, but at 3
> minutes+/run, this could take a long time if we do 10 iterations.  Will 5
> data points averaged out be good for reporting?

Yes, 5 data points averaged should be enough.
(Assignee)

Comment 23

5 years ago
Created attachment 607170 [details] [diff] [review]
Add Talos test for AwesomeBar frecency filter
Attachment #607170 - Flags: review?(gbrown)
(Assignee)

Updated

5 years ago
Attachment #606597 - Attachment is obsolete: true
Attachment #606597 - Flags: review?(gbrown)
(Assignee)

Comment 24

5 years ago
This patch moves the test to the right section of robocop.ini

Updated

5 years ago
Attachment #607170 - Flags: review?(gbrown) → review+
(Assignee)

Comment 25

5 years ago
Pushed:
http://hg.mozilla.org/integration/mozilla-inbound/rev/c46674a93ef0
http://hg.mozilla.org/integration/mozilla-inbound/rev/13a22b4849b4
http://hg.mozilla.org/integration/mozilla-inbound/rev/991782b44d41

Updated

5 years ago
OS: Mac OS X → Android
Hardware: x86 → ARM
Whiteboard: [QA+]
https://hg.mozilla.org/mozilla-central/rev/c46674a93ef0
https://hg.mozilla.org/mozilla-central/rev/13a22b4849b4
https://hg.mozilla.org/mozilla-central/rev/991782b44d41
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 14
https://hg.mozilla.org/releases/mozilla-aurora/rev/92c37fb62be5
https://hg.mozilla.org/releases/mozilla-aurora/rev/804baf4a522d
https://hg.mozilla.org/releases/mozilla-aurora/rev/5c7568cddff5
status-firefox13: --- → affected
status-firefox14: --- → affected
status-firefox13: affected → fixed
status-firefox14: affected → fixed
(Reporter)

Comment 28

5 years ago
I'm still seeing long delay fairly often when loading top sites and about:home (which loads some top sites). Using Nightly build 4/09.
(In reply to Dietrich Ayala (:dietrich) from comment #28)
> I'm still seeing long delay fairly often when loading top sites and
> about:home (which loads some top sites). Using Nightly build 4/09.

Delays are not out of the question depending on the phone, the OS version and the amount of data you have in the DB.

Is it still ~ 3 seconds? The original bug we fixed took a ~15 sec delay to ~2. Using a newer version of Android (with it's newer version of sqlite) took it <1 sec.
Also, do you see a delay when tapping in the awesomebar?
(Reporter)

Comment 31

5 years ago
just tried a cold start and top sites in about:home took 12 seconds to load.

(In reply to Mark Finkle (:mfinkle) from comment #30)
> Also, do you see a delay when tapping in the awesomebar?

i've seen 3+ second delays there recently. i just tried a few times at cold start and got 1-2 seconds.
(Reporter)

Comment 32

5 years ago
ok, if i cold start and as quick as possible focus the location bar, i can get 4 seconds to load it. db contention as top sites are probably also loading?
Verified fixed on:

Firefox 14.0a2, Firefox 15.0a1 (2012-05-02)
Device: Samsung Captivate
OS: Android 2.2
Status: RESOLVED → VERIFIED
status-firefox14: fixed → verified
status-firefox15: --- → verified

Updated

5 years ago
Whiteboard: [QA+]
You need to log in before you can comment on or make changes to this bug.