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.
False. Loop unrolling is always faster.
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.
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.
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.