IIRC, writing to password manager is one of the more blocking and slow operations that Sync performs. (Philipp, do you have any figures from the end of last year?) It would be nice if we could drive the design of an API that matches up more easily with the kind of workload that Sync has, and maybe is more amenable to implementation by OS secure credential storage.

(In reply to comment #0) > IIRC, writing to password manager is one of the more blocking and slow > operations that Sync performs. (Philipp, do you have any figures from the > end of last year?) I do! See https://wiki.mozilla.org/User:Philikon/SyncInstrumentation#Preliminary_results. Talking to the password manager blocks the main thread more than anything else right now. (Satchel has the same problem, except in the forms engine we actually do some queries with our own SQL, asynchronously, so it's not as bad... That said, we need an async batch API for satchel, too.)

(In reply to comment #1) > Talking to the password manager > blocks the main thread more than anything else right now. That's certainly true in terms of magnitude, if not aggregate duration, right? A few things to point out for the record, regarding those graphs: * They are truncated. There's a whole world out to the right that could be super terrifying. * They're total per sync, not adjusted for number of items. That's why history is so predominant, with bookmarks and forms coming in second. This is syncing a few thousand history items, versus 60 passwords. * Passwords has some huge 1800msec outliers. That's not good for user experience, and that's what we hope to address by improving the password manager API.

(In reply to comment #2) > (In reply to comment #1) > > Talking to the password manager > > blocks the main thread more than anything else right now. > > That's certainly true in terms of magnitude, if not aggregate duration, > right? It's true in terms of applying an incoming Sync record. Right now we have to make a trade-off in the password engine between smaller batch sizes (thus blocking the main thread for shorter periods of time) and bigger batch sizes (doing less fsyncs which hurt on mobile). Having an async batch API that does the I/O off thread would get rid of that trade-off altogether.

Newer thinking in bug 853549.