Awesomebar autocompletion is very slow

[grigoryk]

Steps to reproduce

On a device with lots of history and sync enabled, start typing a URL that was already visited many times.
On this particular device, there are a lot of visits to various reddit subreddits. Typing in "red" autocompletes to "reddit.com", but it takes about 200-300ms or so, very visible lag. The more letters I type in, the slower it seems to get.

On other (less frequently visited) websites it's also pretty laggy, but seems to be at least stable as more input is provided.

This started to happen roughly a week ago or so.

cc @tarikeshaq

Expected behavior

Autocompletion in the awesombar is not slow.

Actual behavior

Autocompletion in the awesombar is noticeably laggy/slow as of a ~week ago or so.

Device & build information

• Device: iPhone SE2
• Build version: 103.1 (15076)

┆Issue is synchronized with this Jira Task

[grigoryk]

Happy to see that there are now perf metrics for the awesomebar (#11601), although that doesn't seem to explicitly cover autocompletion cases (but perhaps frecent history + bookmarks is used for url autocompletion?).

[grigoryk]

There was some recent churn around TimeConstants and SQLiteHistory, but it seems harmless? 3012efa#diff-81fb7197aeaf972e86ac0b4c1be58360b1de77a1b37a1b0d565a031a77a3a64cL256 - although I did spend too much time looking at the changes to convince myself that they are (e.g., could it be accidentally querying too large of a time window now?)

[tarikeshaq]

HEYA @grigoryk 👋 👋 !!! thanks for filing this 🙏 🙏 The metrics landed in 105 only (which is still in beta) and we are just starting to see some data back - although given how few number of users iOS has on beta it's not telling us much.

That said, in beta I am seeing a 90th percentile of 300ms, which is a little unfortunate given that fenix is at 160ms ish for it's 90th percentile...

but perhaps frecent history + bookmarks is used for url autocompletion?

Yup from my look into that code, the autocomplete in iOS will run a query every time a user modifies the input, and the metrics I added there track the query, but we don't have enough data back 😖

I'll take a look here to see if recent changes had any impact there, but cc @electricrgb if you can immediately think of a reason why the patch Grisha mentioned could affect autocomplete performance

it's also worth mentioning that we are aiming to use places component in a-s for history around 107/108 (at least that's the current target) and that should change things a little

[adudenamedruby]

I'll mention that we released what was supposed to be 105 as 104.1 as 104.0 had an issue that was really only properly addressed with some significant under the hood changes that were already in 105 and were not really cherry-pickable. So we should be getting those metrics from not just beta, but also prod.

As for why the recent changes had any impact, I can't think of anything off the top of my head because they're either:

1. Just consolidating repeated code
2. Dealing with the user deleting stuff, so that should have zero impact on auto-completion.

[grigoryk]

FWIW, I had to switch to using Focus full-time since the browser is unusable to me right now (i usually use the awesomebar to navigate, so it's pretty frustrating). Can't be that hard to debug? :) I can spend a bit of time next week poking around.

[data-sync-user]

➤ Daniela Arcese commented:

Let’s check this again after we moved to a-s Places

[github-actions]

This issue has been automatically marked as stale. Has the issue been fixed, or does it still require the community's attention? Please leave any comment to keep this issue opened. It will be closed automatically if no further update occurs in the next 30 days. Thank you for your contributions!

[github-actions]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue linking to this one, with up-to-date information. Thank you!