Closed Bug 715264 Opened 10 years ago Closed 10 years ago

Typing in awesomebar is slow

Categories

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

ARM
Android
defect

Tracking

(blocking-fennec1.0 +, fennec11+)

RESOLVED WORKSFORME
Tracking Status
blocking-fennec1.0 --- +
fennec 11+ ---

People

(Reporter: ehsan.akhgari, Assigned: lucasr)

References

Details

to the point of making the browser unusable.  this happens most of the times for me.
wes, can you look at this?
Assignee: nobody → wjohnston
Priority: -- → P2
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.
tracking-fennec: --- → 11+
(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.
OS: Mac OS X → Android
Hardware: x86 → ARM
Lucas - I heard we are opening and closing the DB on every keystroke. Sounds like a performance issue.
Assignee: wjohnston → lucasr.at.mozilla
(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.
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?
I just upgraded to the latest nightly, and it doesn't startup any more. :(
(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?
There's another bug on CyanogenMod with startup. Bug 721431.  Is that the same crash?
bug 725914 should have a positive affect on this issue
Depends on: 725914
Ehsan - Can you re-test?
Keywords: qawanted
blocking-fennec1.0: --- → +
(In reply to Mark Finkle (:mfinkle) from comment #11)
> Ehsan - Can you re-test?

Bug 723295 prevents me from using Fennec on my phone. :(
Status: NEW → ASSIGNED
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?
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
I can reproduce with single core phone and page loading while trying to type in the background.
Keywords: qawanted
(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?
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.)
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.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.