Test Build: Asynchronous location bar

[sdwilsh]

Hmm, yeah. I can confirm the favicon issue.

[093236]

There's a big problem, it uses lots of memory.
And another problem is sometimes it wastes lots of time to execute after I have press the "Enter".

[sdwilsh]

There's a big problem, it uses lots of memory.
And another problem is sometimes it wastes lots of time to execute after I have press the "Enter".

Just so I can try and reproduce these things, I need to know how you came to those conclusions.

Also, on an unrelated note, v0.12 may actually be 0.13. I forgot to change the version in the install.rdf file, but if you update once you'll be on 0.13 which has some fixes in it.

[093236]

There's a big problem, it uses lots of memory.
And another problem is sometimes it wastes lots of time to execute after I have press the "Enter".

Just so I can try and reproduce these things, I need to know how you came to those conclusions.

Also, on an unrelated note, v0.12 may actually be 0.13. I forgot to change the version in the install.rdf file, but if you update once you'll be on 0.13 which has some fixes in it.

Yes, I have updated to 0.13, it can show the favicon
For the memory problem, for example: type "thunderbird", and press the "Backspace" once, and press the "d", it also uses lots of memories to do that.

For the "Enter" problem, it might be cause by using the keyword.

[sdwilsh]

New version of the add-on is out. Check for updates to get it.

[sdwilsh]

In bug 481227 I'm working on making favicon requests asynchronous. I suspect this might help location bar performance, but has nothing to do with asynchronous location bar searches. I'd be interested to know if this build helps anyone who has a laggy location bar:
https://build.mozilla.org/tryserver-bui ... b80e57a92/

[sdwilsh]

Those of you seeing high memory use should try the add-on with tomorrow's nightly. I just fixed a leak in storage that this would certainly be hitting (https://bugzilla.mozilla.org/show_bug.cgi?id=482614)

[sdwilsh]

I know it's been a while, but I've started working on this again. The add-on will not be updated any longer (I don't want to have to do a binary component), but I've got test builds that should start showing up here:
https://build.mozilla.org/tryserver-bui ... ee572ff69/

[sdwilsh]

New builds:
https://build.mozilla.org/tryserver-bui ... b9b91f7d7/

Feedback is really appreciated folks. This work is on the home-stretch before landing, so it would be nice to get feedback if something is up. This has been working great for me locally.

[sciguyryan]

I just installed the latest build above and the speed improvement is massive from what I see here. After you type there is a very small wait before the result appear. On current nightly builds the hang if much greater.

Nice work guys. I'm not seeing any speed decrease here but am seeing a large speed gain.

[Izbitzer]

Nice work guys. I'm not seeing any speed decrease here but am seeing a large speed gain.

Same here! Excellent work!

[XtC4UaLL]

I copied my "daily usage" 70 MB places.sqlite in a new profile for testing this and noticed following:

whilst querying a term in the location bar, the first entry is shown for a brief second including scrollbars in the awesomebar drop-down and then the other results are being populated:

this does not happen on MC trunk.

here a quote from the places stats script result for above used places.sqlite.:

Code: Select all

 "places_file_size":74084352,
 "moz_anno_attributes_cnt":22,
 "moz_annos_cnt":1543,
 "moz_bookmarks_cnt":6778,
 "moz_bookmarks_roots_cnt":5,
 "moz_favicons_cnt":3185,
 "moz_historyvisits_cnt":221861,
 "moz_historyvisits_temp_cnt":108,
 "moz_inputhistory_cnt":118,
 "moz_items_annos_cnt":6179,
 "moz_keywords_cnt":93,
 "moz_places_cnt":119092,
 "moz_places_temp_cnt":47,
 "bookmark_cnt":6316,
 "folder_cnt":431,
 "separator_cnt":31,
 "dynamic_container_cnt":0,
 "bookmark_nontag_cnt":4602,
 "livemark_container_cnt":1,
 "livemark_child_cnt":39,
 "visits_per_place_avg":1.8662443956561603,
 "visits_per_place_max":3094,
 "visits_per_place_min":1,
 "places_visited_unique_cnt":118881,
 "visit_date_oldest":"Sat 08 Mar 2008 18:59:31 GMT",
 "visit_date_newest":"Wed 08 Jul 2009 09:29:37 GMT",
 "visit_date_avg":"Sun 23 Nov 2008 16:57:39 GMT",
 "tag_cnt":56,
 "tag_size_avg":30.607142857142858,
 "favicon_data_size_avg":542.5500784929357,
 "favicon_nonnull_data_size_avg":542.5500784929357,
 "favicon_nonnull_cnt":3185,
 "session_unique_cnt":14895,
 "frecency_first_bucket_visit_cnt":2569,
 "frecency_second_bucket_visit_cnt":6266,
 "frecency_third_bucket_visit_cnt":14656,
 "frecency_fourth_bucket_visit_cnt":39482,
 "frecency_first_bucket_place_unique_cnt":1894,
 "frecency_second_bucket_place_unique_cnt":4282,
 "frecency_third_bucket_place_unique_cnt":9768,
 "frecency_fourth_bucket_place_unique_cnt":24853,
 "history_expire_days":999,
 "history_expire_days_min":999,
 "history_expire_sites":40000,

(it didn't allow me to submit, stating malformed data ...)

[sdwilsh]

whilst querying a term in the location bar, the first entry is shown for a brief second including scrollbars in the awesomebar drop-down and then the other results are being populated:

this does not happen on MC trunk.

I'm not 100% sure if you are saying that this is a bug or not.

[XtC4UaLL]

I guess so. Maybe that is what is described in https://bugzilla.mozilla.org/show_bug.cgi?id=455555#c74 as "flashiness.."?!

[sdwilsh]

I guess so. Maybe that is what is described in https://bugzilla.mozilla.org/show_bug.cgi?id=455555#c74 as "flashiness.."?!

Yes - quite possible that that is what you are seeing.