715264 - Typing in awesomebar is slow

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect, P2)

Description

[(no longer active)]

to the point of making the browser unusable.  this happens most of the times for me.

Comment 1

[Doug Turner (:dougt)]

wes, can you look at this?

Comment 2

[Wesley Johnston (:wesj)]

ehsan, i don't suppose you can provide a bit more info? Nightly builds I assume. The type of device? Any clue how big your history is (I may need to add some logging for us to get that)?

What exactly do you mean by "slow"? The characters appearing in the text box lagging behind your input, or the awesomescreen results appearing late? Can you give a rough wall clock amount of time for either/both to happen?

I'm adding some logging to track query times in bug 709078. I can look at adding some info about history and bookmarks list sizes as well.

Comment 3

[(no longer active)]

(In reply to Wesley Johnston (:wesj) from comment #2)
> ehsan, i don't suppose you can provide a bit more info?

Sure.

> Nightly builds I
> assume.

Correct.

> The type of device?

Galaxy S Vibrant running CyanogenMod.

> Any clue how big your history is (I may need to
> add some logging for us to get that)?

It's hard to tell, since Fennec does not have a UI to show the history.  I see tons of stuff in my awesomebar.  I think my history was migrated from my XUL profile, which used to be synced with my desktop history, which I used to sync to my main desktop profile.  I tried clearing all of the history in the stock browser in the hopes that it would make things better, but nothing changed in terms of the awesomebar performance.

I should also note that the XUL Fennec used to handle my synced history relatively well.  It used to be slower than the stock browser, but not as slow as native Fennec.

> What exactly do you mean by "slow"? The characters appearing in the text box
> lagging behind your input, or the awesomescreen results appearing late? Can
> you give a rough wall clock amount of time for either/both to happen?

The issue is both with the input lag, and the delay in updating the awesomebar entries.  There is also a visible delay in showing the initial entries after I tap the urlbar.

I just did a test, and here's what I saw:

Tapping the awesomebar took about 15 seconds to show the initial awesomebar UI.  Then I got the "Activity Nightly is not responding" dialog, with options to Force close or Wait, to which I said wait.  Then about 30 seconds later, I got that dialog again, and said wait again.  The same thing happened three times more, and I gave up and killed Fennec. :(

In my testings the past few days, I have only been able to use the awesomebar to navigate to a web site maybe half of the time.  The other half I have gave up and killed Fennec after 2-3 minutes of trying to enter something inside the awesomebar.

> I'm adding some logging to track query times in bug 709078. I can look at
> adding some info about history and bookmarks list sizes as well.

Sounds good.  Let me know how I can help with testing.

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

Lucas - I heard we are opening and closing the DB on every keystroke. Sounds like a performance issue.

Comment 5

[Lucas Rocha (:lucasr)]

(In reply to Mark Finkle (:mfinkle) from comment #4)
> Lucas - I heard we are opening and closing the DB on every keystroke. Sounds
> like a performance issue.

Hmm, AFAIK, the DB connection is kept open as long as we're using the ContentProvider. I'll double-check.

Comment 6

[Lucas Rocha (:lucasr)]

Ehsan, I've done some perf improvements on the awesomebar query after you filed this bug. Could you try the latest nightly and report back if anything has improved for you?

Comment 7

[(no longer active)]

I just upgraded to the latest nightly, and it doesn't startup any more. :(

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Ehsan Akhgari [:ehsan] from comment #7)
> I just upgraded to the latest nightly, and it doesn't startup any more. :(

Crap - got a logcat?

Comment 9

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

There's another bug on CyanogenMod with startup. Bug 721431.  Is that the same crash?

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

bug 725914 should have a positive affect on this issue

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

Ehsan - Can you re-test?

Comment 12

[(no longer active)]

(In reply to Mark Finkle (:mfinkle) from comment #11)
> Ehsan - Can you re-test?

Bug 723295 prevents me from using Fennec on my phone. :(

Comment 13

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Hi Ehsan, may we get an update please?  looking at https://bugzilla.mozilla.org/show_bug.cgi?id=723295#c21 that had seemed to remove your blocker?

Comment 14

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I found that typing can be slow if the web content is loading in the background while typing in the awesome page/urlbar with the Galaxy Captivate

Comment 15

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I can reproduce with single core phone and page loading while trying to type in the background.

Comment 16

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Ehsan Akhgari [:ehsan] from comment #12)
> (In reply to Mark Finkle (:mfinkle) from comment #11)
> > Ehsan - Can you re-test?
> 
> Bug 723295 prevents me from using Fennec on my phone. :(

What about now?

Comment 17

[(no longer active)]

This doesn't happen any more, but now I have a fresh install with only a handful of pages in the history, so I don't think I am testing what I was seeing in comment 0 (we used to share the places DB with the stock browser back then IIRC.)

Comment 18

[Lucas Rocha (:lucasr)]

The talos test I just pushed (see bug 730105) show that our db queries are fairly fast even for a big number of history entries (10k). I really doubt there's some big performance hit on UI level because list view is very smart about only loading/inflating visible rows (so it doesn't matter if our listview has 10k or just a few dozens of rows, it will roughly perform the same).

I have also recently enabled the perf improvement on our awesomebar query which probably has a big impact here (see 735660).

So, I'm closing this bug as WORKSFORME. Feel free to re-open if you still see performance issues while typing in awesomebar.