For the record, chrome on android is ~60MB, less than half the size of desktop chrome (~150MB). Android chrome supports the same set of javascript APIs. Clearly that isn't the whole picture.
*correction, according to https://developer.chrome.com/multidevice/webview/overview they are still separate, it references android L dev preview so not the latest source tho...
While 60MB is still humongous, it does make sense that Google would at least care slightly on Android, as the majority of the Android market are low-to-mid-tier smartphones with reasonable performance instead of the "desktop-in-a-pocket" that are the current flagship phones.
But while they care slightly on Android, they don't care at all on desktops.
Remember kids: Large binaries are slow binaries.
False. Loop unrolling is always faster.
See, the hardware folks have listened in on the compiler people and their problems. They've done things like identify loops and rewritten them in microcode for optimization. If a short loop can fit entirely within the CPU code buffer, speed goes way up. Unroll the loop and blow the CPU code buffer, defeat the optimization and lose all that.
Blatantly false, which is why heuristics decide when to unroll.
Large code trashes instruction caches, and cache misses are very expensive. More code, more misses.
For very small loops, the unroll can pay off, but these are often too small to have significant size detriment.
And yes, there is clearly only an incentive to care on Android. The automated tooling to track Chrome binary size only works on the Android build.