Search performance, or perceived performance needs improved

[DarkArc]

I'm not sure why, but it at least feels like the old app searched faster. I've been searching for passwords on several occasions with "no results" only to get a result after I had mentally given up, and felt like that was the final answer.

I generally love the new app, but this has lead to me feeling noticeably confused. I've also noticed if my phone changes "foo" to "Foo" the entire search disappears and resets, one major improvement might just be simply processing the entire search string as lower case, and not rerunning if only the case changed.

One of my most common workflows on mobile is searching for and copying a password, so any improvements to search performance or perceived search performance would be much appreciated.

Worth noting, I don't have a particularly slow, or low end phone; it's the Pixel 2XL.

[kspearrin]

I've also noticed if my phone changes "foo" to "Foo" the entire search disappears and resets, one major improvement might just be simply processing the entire search string as lower case, and not rerunning if only the case changed.

I am not able to reproduce this issue. Search should already be case insensitive.

[DarkArc]

I am not able to reproduce this issue. Search should already be case insensitive.

Interesting, it's 100% reproducible for me, it requires a word to be typed either partially or completed for instance "hoover", then the suggestion "Hoover" to be selected. When the selection is made, the search reruns.

This is using Gboard as the keyboard.

Perhaps it's deleting the word, making the search an empty string, then almost immediately replacing it with the new title cased version of the word, making it a "change" from nothing to something, but not really from the user perspective?

[kspearrin]

@DarkArc I was able to reproduce this on my Nexus 5X with gboard. It seems that I am getting two search events whenever you tap the capitalized word suggestion. The first is an empty string, immediately followed by the new capitalized string. I don't know if this is a bug in the framework or what, but because the previous value (empty string) is not the same same as the new value, it fails that logic check to not search if the value is the same.

[DarkArc]

Thanks Kyle, glad you were able to reproduce it. Perhaps a short debounce on searching could be used so that only the final result (i.e. the new word) is compared?

[DarkArc]

This manifested in a weird way today. I've seen it before, but this time I was paying more attention.

If you have something stored like "Foo Bar", quickly type "foo", then press the search button on the keyboard, you can end up with "There are no items to list." even though there is indeed a valid item to list.

It's like the search button is somehow stopping it from going from that empty state to new value as far as the search system is concerned, or something. That said, the word "foo" remains in the search box. If you go back to the search box, and press search on the keyboard again, the results will appear.

[alextmz]

Also feel like the older versions are faster; however, I did not test specifically for this and it may be subjective. Phone is a Pixel 1 XL on android Q.

My experience is that, right after the biometric auth, while the "loading" spins, if I immediately click "search" and type away, results take around 10 secs (timed) to come up. They "feel" a little bit faster if I wait for the data to appear then search, but again may be subjective.

I've wonder if the speed hit is due to a large number of passwords, some binaries (doc images) stored on the vault, or the new versions are slower. Did not investigate but happy to run a debug/profile version if available to help fix this. 10 secs when you need the pw straight away is a long time...

[AyoungDukie]

This is also occurring for me on a Pixel (sailfish). Seems to be particularly sensitive during the first loading of data after a vault unlock, but rather snappy after. Is it potentially trying to fully refresh the vault on unlock? Would it make sense to allow for caching/incremental updates on this type of action, and leave full syncs to be done periodically in the background? I believe this is how I have seen competitor products work around allowing the user to relock the vaults frequently, which is obviously desired besides the performance hit.

[3xploiton3]

Also feel like the older versions are faster; however, I did not test specifically for this and it may be subjective. Phone is a Pixel 1 XL on android Q.

My experience is that, right after the biometric auth, while the "loading" spins, if I immediately click "search" and type away, results take around 10 secs (timed) to come up. They "feel" a little bit faster if I wait for the data to appear then search, but again may be subjective.

I've wonder if the speed hit is due to a large number of passwords, some binaries (doc images) stored on the vault, or the new versions are slower. Did not investigate but happy to run a debug/profile version if available to help fix this. 10 secs when you need the pw straight away is a long time...

same happen on me, redmi note 5,
i already disable all other app, i think that's the problem, but issues come from bitwarden itself

[wjhrdy]

I have this issue as well on my Pixel 5.

Right after the biometric auth, if I immediately click "search" and type away, results take around 7 secs (timed) to come up.

It also happens with autofill.

Seems like the sync process is blocking the search proceess.

[clemlesne]

Hello, I can confirm this issue, either on a Samsung Galaxy S20+ and on a Samsung S21 Ultra.

Searches are always slow, few seconds delay. From a user point-of-view, this is frustrating.

Any improvements to imagine with, perhaps, better indexing or another embedded DB?

[AyoungDukie]

I had been writing this off as a sync occurring, but I am not so sure now.

I actually encountered an odd occurrence recently where I was trying to log into an app on my phone (via autofill from Bitwarden), but using a login I had just recently created on my desktop browser.

• Encountered the described slowness, but the new login was not found.
• I then opened the app directly to scroll through the login list, and it wasn't there.
• After checking the sync time, it turned out it was still from prior to me creating the login, i.e. the delay wasn't from syncing

Like I said, this was a very specific occurrence, but it does make me think there is something else going on.

[AyoungDukie]

Just to post an update, for me. On Version: 2.16.2 (4334), and one of the first few recent updates seems to have noticeably improved this. Thanks to the team!