25 February 2009 - 10:44Looking for Location Bar Perf. Testers
I’ve got a change that should speed up the Location Bar in Firefox 3.1 and 3.2, but I just want to make sure it’s not only me and my computers that are seeing this benefit.
For you to take the test, you’ll need to be running a Shiretoko (Firefox 3.1) build or Minefield (Firefox 3.2) build [ftp.mozilla.org].
What you then need to do is type something that will search through all your history, such as “this page isn’t in my history yay”. Just copy/paste that into your location bar, but keep track of the time you pasted and the time the activity throbber stops spinning in the location bar. (If you do get results, it’ll still be okay, as long as the location bar didn’t find 12 results.)
Depending on how much history you keep and how long you’ve been using Firefox 3, this could take over a minute or two before the throbber stops spinning.
Once you record how many seconds it takes for the throbber to stop, repeat the same thing with the Firefox 3.2 build that includes my optimization [build.mozilla.org].
CPU Usage (1 bar/sec): Old Firefox 3.1 takes 2 minutes; New takes 20 seconds
I’ve tested this on a few Places databases with my current unibody MacBook and my old iBook, and both times it runs much faster. Some times it goes 6 times faster. With one test on a database with over 100,000 places, the location bar throbber stop spinning in 20 seconds instead of 120 seconds.
Please report back your results as comments, and if you’d like, go ahead and vote for the bug, Make location bar autocomplete even faster [bugzilla.mozilla.org], to follow its progress.
30 Comments | Tags: AwesomeBar, Mozilla
Oddly, Shiretoko from two weeks ago took 9 seconds, and Shiretoko from last night took 25 seconds. It’s my working profile, with a very rich profile. I have a feeling my test run wasn’t good.
On an AMD 64 X2 3800+, Windows XP x64, with lots of stuff running in the background on a places database of just short of 37’000 entries the run time dropped from approximately 43 seconds to 13 seconds.
The build tested with 43 seconds was:
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20090224 Shiretoko/3.1b3pre ID:20090224033427
Although selecting all my history items in places to see the total amount froze Firefox for 20 seconds or so and leaving it open in the background once it had finished eventually gave the error:
“A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
Script: file:///C:/Program%20Files%20(x86)/Minefield/modules/utils.js:302”
I tried again on my Mac using my working profile, with clean snapshots of my profile.
Shiretoko (2.13.2009): 45 seconds
Shiretoko (2.24.2009): 29 seconds
3.2 (edilee’s tryserver build): 25 seconds
I think the firs time I inadvertently clicked on my touchpad, while the first test was running, which is why throbber stopped spinning at 9 secs.
Great news Edward! Any performance improvements for the location bar are very welcome.
From 19 seconds on a recent trunk build down to 10 seconds. Not bad!
Holy Crap! On my ancient AthlonXP 2400 and with a new profile but with my usual places.sqlite (1yr of history), searching in the addressbar for the term ‘amcdefghijklmnopqrstuvwxyz’ (which doesn’t exist)
2m20s — Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090225 Shiretoko/3.1b3pre ID:20090225031913
0m45s — ../tryserver-builds/2009-02-22_18:47-edward.lee@engineering.uiuc.edu-combine.select build
Wallclock times on my computer (Pentium 4, 300 days of history) – did a couple of runs with each
25 Feb Windows trunk build: 47 secs, 45 secs
Your try server build: 19 secs, 20 secs
I used the awesomebar for some 1-2 letter matches, and didn’t notice any adverse effects…
Whereas this improvement means a quantum leap in productivity, the delay measured in tens of seconds is still not quick enough from the usability perspective to be assumed user-friendly.
Is there any way to load the index of history database into memory? How does Google indexes your desktop’s files with its Google Desktop Search?
3.2a1pre latest, Windows XP 32bit:
Your build: 44 seconds
normal build: 175 seconds
machine: 1.8 GHz intel centrino slowed down to 600 MHz, 1 GB RAM
history: ~41,000
bookmarks: maybe 7,000
Firefox 3.1b2 takes about ~11 seconds
Your build: ~6 seconds
That’s about 1/2 the time, I like it.
Funtomas: Lots of pre and post processing, Firefox could do the same if you were willing to wait around an hour or so while it indexes the history every now and then.
Thanks Damian. Well, wouldn’t it be a better approach to keep whole index in memory and update (i.e. analyze it via statistics computation) it with each write into the history table?
Usability should be the main driving factor here otherwise Old Location Bar add-on bubbles up in the popularity top-ten chart.
Funtomas: I’m going to take a guess here, but my places file is 22 MB, so it’s a pretty large overhead hit on the memory. Then this is exactly the sort of thing which is probably going to suffer pretty badly from memory fragmentation over time. Doesn’t sound like a very good mix…
Plus wouldn’t it be extremely difficult to not suffer an unacceptable chance of massive data loss?
“wouldn’t it be a better approach to keep whole index in memory and update (i.e. analyze it via statistics computation) it with each write into the history table?”
Doing anything with each write to history will slow the browser down. Lots of people hate the large amount of memory that Google desktop uses.
I’m not sure the speed of anything is a factor in the “Old location bar” downloads – that’s first because people don’t like changes, and also because they want more control over what appears in the bar. Firefox 3.1 has more options which do the same things that Old bar and other add-ons are doing in 3.0.
Meanwhile, I see that this change has now been checked in to the nightly builds, so that’s good 🙂
> the delay measured in tens of seconds is still not quick enough
Just to point out, these long delays are only for not matching anything in your history. The location bar does a great job bringing the pages you frequently visit to the top of the list for you to immediately choose it.
Add in the adaptive learning, you’ll only need to type a single letter to get to where you want to go.
> Lots of pre and post processing
The way the history works is that we calculate a “frecency” rating for each page from time to time, and this is stored as the index for the history pages. This means it’s very quick to access pages by their frecency.
One of the ways the location bar shows results is by frecency, so this pre-computation of frecency helps immensely. Additionally we do some post processing of frecency when you’re idle to update the index to your recent browsing behavior.
> I’m not sure the speed of anything is a factor in the “Old location barâ€
People are probably using it just for the single-line look. But the engine providing the results to “old location bar” are the same as the one for the Awesome Bar.
> this change has now been checked in to the nightly builds, so that’s good 🙂
Yup! Thanks everyone for helping test this. There’ll be even more optimizations coming in, and they might make it to 3.1 if there’s time. One direct example is the “async location bar” by Shawn. He’s updated his add-on to make use of this post’s optimization, and now it’s going even faster!
3.2a1pre latest, Windows XP 32bit:
Your build: 7 seconds
normal build: 7 seconds
@idragonet: You have tested 2 builds containing the change (so it makes sense that they are the same) – if you want to see the difference between the old code and the new code, you need to compare with a nightly build from before 25 February.
Linux, Mac users, do this regularly: http://weblog.savanne.be/153-performance-tip-of-the-day . My Firefox 3.0 only needs about 10 seconds to search for “abcdefghijklmnopqrstuvwxyz” (1.7 GHz single-core). It also exits immediately now.
[…] web he observado una mejora importante, que en general ha sido alrededor de un 15%. En una versión modificada por Edilee se han conseguido incluso mejores resultados según leo en los […]
[…] already posted about speeding up the location bar, and it’s made it into Firefox 3.2 already. On the way there, used Andrew Sutherland’s […]
I installed the Firefox Beta just for the hell of it. Now I find that I don’t understand what all of you are talking about. Ithink I need something in the way of a tutorial to understand this Beta. Any suggestions,
Ernie
[…] blog. Spurred on by one of Shawn’s performance wins, Ed Lee was able to drastically speed up searching in the Awesomebar. Even now, we’re working on changes that will vastly improve the performance of the history […]
Where can I find definitive and detailed information about all the functionality that the awesomebar provides (including what new functionality was added in FF3.5)? I keep thinking I’m missing something, as I don’t find it all that awesome, and a reference to “improved tagging” made me wonder what tagging functionality it provides, as I haven’t found any myself…
Marcus, tagging has been provided since 3.0 and it’s a bit hidden. It’s actually buried under add-to-bookmarks star icon, when clicked second time. In 3.5, tag names suggestions have been added. To tweak the AB features, type in “about:config” to your URL bar and then use filter “browser.urlbar”.
Ah, I see. Well, I don’t use Firefox’s bookmarks at all because it ties me to a single machine and Weave doesn’t help because I don’t have admin rights over all installations of FF that I might need to use, so Del.icio.us remains my bookmarking service of choice. With that in mind, are there any plans to open up the Awesomebar bookmarking/tagging functionality for use/integration by 3rd party services?
And my question about a definitive list of Awesomebar functionality still remains…
So not a definitive list, but I’ve got a post describing the new 3.5 about:config preferences:
http://ed.agadak.net/2009/02/firefox-31-location-bar-preferences
I happen to be working on Weave as well 😉 But what do you mean by admin rights? Weave is an add-on that doesn’t require any admin privs. You should be able to install it just like any other add-on. Are you concerned about syncing only certain data to certain machines?
Thanks for the link to the prefs article, that certainly helps.
With regard to Weave, you’re right of course, no admin rights required. I suppose what I meant in hindsight was the admin hassle of having to find and install Weave, then restart, and finally configure it every time I use a new Firefox installation, just to get my bookmarks! This simply isn’t practical for me, and the advantage of Del.icio.us is that I can access the bookmarks through its site from any device in the world (and any browser) just through a simple login form, its add-on is merely a bonus. Locking my bookmarks away in a FF-only store that’s hard for even me to get to from a virgin Firefox installation isn’t very attractive at all in comparison.
We do have plans for setting up a website that you can have the browser decrypt your data and show the bookmarks. The current issue is that it’s very slow on browsers with slow javascript engines, but on Firefox 3.5, it’s decent.
Ideally, we’re trying to get the platform to provide something like navigator.crypto.decrypt to provide a fast native decrypt implementation.