Sometimes less cached data is produced

[jrieken]

Checking the disk usage of cached data files shows large variation. This smells like V8 is sometimes running without the no-lazy switch. We use that switch to load/parse the full body of code so that we generate much more cached data.

jrieken:~/Library/Application Support/Code - Insiders/CachedData$ du -sh *
 18M	11b0f3a40be055e02b721abbb93cb0012818f99e
1.2M	2cb30794e7e0b4edd2907be895a0410fd601b736
 18M	777c8e57e0eb1cbffb87a57ffd4f9c3d274f9429
 18M	7dc9539a421c9c33e57e2ce0b718f183bb44c756
1.2M	b4a18da6e78f95295ea6538f5ae8dd0c9f0869a9
 18M	c51cf862a9604dffe2e3e8792a4b0a45213869a3
1.0M	c5c7d43b65bcbbb3851fbd972fad077631c707e3
1.2M	dc15008ccb1132fe39560c99beaf314fdb1f7cd7
1.2M	e585e4bf008a50e5b1f4fde71cf6d255e25381bf

[jrieken]

One theory is that this is due to use setting the --js-flags-async, after resolving cached data location. That might be after the app-ready event which means switches aren't honoured anymore. However, the the app-ready event comes after ~150ms which should be enough slack time for a simple folder stat...

[jrieken]

@joaomoreno this seems to be a regression from d631cb8. The mkdir function doesn't resolve with the directory anymore (as it used to). In consequence mkdirp doesn't resolve with the directory anymore and ultimately no value is provided here: https://github.com/Microsoft/vscode/blob/ede8a0f336d86f530077d5c0509f01c8eac947f9/src/main.js#L404:L410