Looking at issue 52663 turned up a lot of updates to Cookies. Some of these were unintentional (a threshold for updating has incorrect units), but I think things could be improved further.
WAL mode might be reasonable for Cookies. Since it doesn't do fsync(), the OS could then use whatever buffering magic it is configured for. Orderly close would fsync(), so everything should work the same in most cases. Chrome-level crashes should also work fine, but OS-level crashes could lead to cookies not actually being saved. OS-level crashes can lead to that outcome without WAL mode, too.
The threshold referenced above is about how frequently to update the last-accessed time. From what I can tell, this is a pretty high-volume item. It may be reasonable to pend those updates in memory and piggyback them on other updates, and/or flush them on orderly shutdown, and/or give them a longer threshold (right now it's 60 seconds). AFAICT the only time it's really going to matter is in garbage collection, where it won't matter too much if the heavily-used cookies have last-access in the newest 10% or top 25% of your cookies, just that they don't go from the newest 10% to the oldest 10%.
I'd also like to get in and inspect the kinds of deltas we're seeing. Perhaps there are cases where we're injecting changes which really aren't important to persist immediately.
Comment 1 by sh...@chromium.org
, May 18 2016