nice find!! We do not have F2FS coverage on perf waterfall, so evaluating this seemingly small change, if so needed, may turn out to be quite involved.

Adding third_party/sqlite/OWNERS for a few questions to clarify together:

1. What metrics should we look at to determine whether it improves something?

2. This is a compile-time flag, so doing a Finch is not as convenient, would it justify not doing a Finch study? :)

PS: this could be one more reason to ask for enabling /proc/pid/io metrics on Android kernels, but that's another story..

Actually adding third_party/sqlite/OWNERS: please see the questions above.

This is actually a feature, classifying as such.

An external contributor put together https://crrev.com/c/1003012 which attempts to turn on the flag. The CL doesn't handle WebSQL's special usage of SQLite, which can be seen as LayoutTest failures. The CL seems abandoned.

1. I suspect you want Sqlite.CommitTime.* and SQLite.AutoCommitTime.*, maybe Sqlite.MemoryKB.*

2. Yeah, Finch is always painful for config changes.

I am not going to ask for a Finch trial. I think this is a net-positive, and we should do it, if we can figure out the WebSQL story.

If someone else asks you to do a Finch, you'll have to figure out how to disable batch atomic writes in SQLite's VFS layer, based on the Finch flag. I propose that we look into this after we have a CL that passes CQ (in other words, handles WebSQL) and a request for a Finch trial.

Should you need a Finch trial, https://crbug.com/875538 might be helpful.

pwnall: thanks for all the info!

Thanks pwnall@. I looked at crrev.com/c/1003012's layout test failures but didn't get much insight into what's going on. Do you have an idea of what WebSQL is doing that is causing problems?

Background: we're thinking of this for a starter project for a new hire, but only if it's not too messy.