Browser: Slow performance when creating new item

[egnirra]

We're running a selfhosted Bitwarden with 4000+ passwords.

When creating a new item it takes more then 1 second to update.
As seen in the console "search indexing: 1485.450927734375ms"

Max CPU Usage on any of the containers is ~4% .

When i first login it takes a long time to load, and also each time i have to unlock after that.

As my chrome tab runs att 100% CPU when doing any of this i would assume the issue is client side.
When creating new items, it seems it needs to sync everything instead of just the single item i just created, which then requires a decryption which takes a lot of CPU time on the client.

The same issue is replicated with the Windows app as well.

[kspearrin]

Looks like the time is being spent rebuilding the search index, which we can't do incrementally that I know of. I don't know if I have a solution at the moment. Maybe we could provide an option for users with large vaults to disable advanced search capabilities with lunr. https://help.bitwarden.com/article/searching-vault/

[egnirra]

Thank you for your response @kspearrin
It's fine for general use but if i need to create a lot of items it makes for a bad experience when i just stare at the screen waiting for it to finish each time.

I doubt we would use advanced searches and could in that case turn it on if we need (if it's possible to make it an option)
Let me know if you want me to try anything to see if it speeds up the index.

It seems lunr 1.x supported adding new objects without rebuilding but removed in 2.x

Unless it's possible to pre-build index server-side

[xcffl]

Looks like we can save the built index to the browser storage (probably encrypted), as @egnirra says. It doesn't need to be built at the server side, because Bitwarden WE is not in client-server model.

This will help:

• freeze when unlock Bitwarden
• freeze when add an new item

[xcffl]

After reviewing the code, I think it's good to do off-main-thread indexing instead of do caching by hand.
Async/await is not enough for such a heavy job (async/await excutes code in a single thread). Theoretically background.js works. But it doesn't seems to be the case for Bitwarden.

The problem turns out to be the method Bitwarden used to access background scripts from the options pages. That makes them be in the same thread or so.

[xcffl]

Alternatively, replace lunr with flexsearch(https://github.com/nextapps-de/flexsearch/blob/master/README.md#index.add) is also a good idea, which not only supports adding items to index, but also promises a much better search performance.

[egnirra]

@xcffl
Thanks, the flexsearch option sounds like a good solution, being able to adding items to index and better perf seems from their own testing to be really good.

[xcffl]

@kspearrin will a PR on this be considered?

[xcffl]

If there is data integration consideration, a less invasive option is to use requestAnimationFrame(). I think it will be a small patch.

Bitwarden Mobile also has this problem, although I do see a lot of use of Task. I'll have a look after this is fixed. After a peak I found it does have some room for improvement (such as something shouldn't be blocking).