From build.chromium.org, you can click the "perf" link in the upper left to see some of the metrics we track over time. This drill-down into startup shows around r2800 we regressed startup by about 3ms, and you'd be surprised to see how much effort has been put into getting those three milliseconds back. (Normally you'd just revert the commit, but that one in particular contained about six months of work on WebKit. Large jumps on other perf graphs are related to that as well.)
Linux apparently has no way to do non-blocking IO to the disk. (Many people hear that and begin with "What about the aio/myfavoritescheme functions?" but the answer as far as I can tell is that those don't work.) It's not too hard to put disk operations on yet another thread, but it's unclear to me which parameters of a thread pool would help -- there's a trade-off between thrashing between multiple spots on the disk vs getting more data in front of the disk scheduling algorithms, etc. Anyone have anything smart to say about it?