[BUG] Delay searching password list

[madduck]

Describe the bug

I have roughly 1,300 passwords in my store, and when I fire up the UI (or try to use autofill) to search for a password, it takes a few seconds for the results to show up. I kinda expect filtering of the resultset to be instantaneous, and 1,300 entries isn't exactly a big search task even if search were to be done linearly, but the filesystem itself already does some sort of B-Tree, so this is a bit hard to understand.

Steps to reproduce

Steps to reproduce the behavior:

1. Open the app, or engage autofill
2. Enter search term into search field, e.g. "github"
3. Wait 2–3 seconds before the list is refreshed
4. …

Expected behavior

As I hit 'g', I expect the list to hide all entries not containing a "g", and the "g" in matching entries to be boldened. When I hit "i", the list again updates instantaneously.

Screenshots

No response

Device information

• Device: Google Pixel 6 Pro
• OS: GrapheneOS, Android 12
• App version: 1.13.5

Additional context

No response

[msfjarvis]

I added a benchmark to our fuzzy search library and it was made abundantly clear that the problem is not with it after it was able to do 2000 matches of strings ranging in length from 0 to 2000 characters in an average time of 72ms

> Task :benchmark:jvmBenchmark
Running 'main' benchmarks for 'jvm'

… benchmark.FuzzyMatchBenchmark.fuzzyMatch

Warm-up 1: 72.604 ms/op
Warm-up 2: 71.629 ms/op
Warm-up 3: 71.327 ms/op
Warm-up 4: 71.534 ms/op
Warm-up 5: 74.636 ms/op
Iteration 1: 72.064 ms/op
Iteration 2: 71.990 ms/op
Iteration 3: 72.567 ms/op

  Success: 72.207 ±(99.9%) 5.729 ms/op [Average]
  (min, avg, max) = (71.990, 72.207, 72.567), stdev = 0.314
  CI (99.9%): [66.478, 77.936] (assumes normal distribution)


jvm summary:
Benchmark                       Mode  Cnt   Score   Error  Units
FuzzyMatchBenchmark.fuzzyMatch  avgt    3  72.207 ± 5.729  ms/op

I'll investigate the app side of things in a couple weeks and see if we can track the problem.

[msfjarvis]

Testing with our pass-test dataset confirms that there is definitely delays in the UI, investigating now.

[msfjarvis]

The specific code block that causes the delay is this but I haven't yet figured out why it's slow. Will take another look later and see if I get any ideas.