Investigate Asynchronous File IO

[DanielRosenwasser]

@amcasey has some ideas for speeding up IO times by making our read/write calls asynchronous. This issue tracks that and should be the place to document the outcome of the investigation.

Also related: #1857, #16607, #29100

[amcasey]

I spent a week or so of this, without reaching the end of the cascading async-ness changes, so I don't have empirical performance numbers. However, @weswigham and @ahejlsberg have suggested that the overhead of making a very simple function promise-returning is unjustifiably high. I think we're going to put a pin in this and look for other ways to speed up I/O.

[weswigham]

Cascading async: Bad. async cordoned to one top-level await: Good. Using Promise.all with await to pull together many async reads at once: Very good.

The v8 team did an optimization pass on async functions once before (and then reverted it?) - but their comparison "benchmark" was raw promises. async/await under common usage patterns should enable near-normal-call performance (nothing async is done -> no full promise allocated -> near-immediate return to execution), but there hasn't been a drive to invest in that yet. :(

Or my brief tests were poisoned by this v8 perf bug. Can't be sure.

[amcasey]

For build mode, I believe it's possible to do that for file writing and only cascade it back up the spine. File reads are more tightly integrated and we'd have to be a lot more explicit about when a lazy read actually happens (i.e. async before the read, sync after the read). We'd almost certainly have to give up some laziness to get that and it's hard to say whether we'd come out ahead.

[amcasey]

I'm working on this, but don't expect a fix to land in 3.8 - updating the milestone to reflect this.