4 ms·

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

by tbodt 6y ago

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.

jan6 6y ago
I'm preeettty sure that's just because it's relying on the separate WebView app, using WebView is also how it's possible for people to make sub-megabyte android browsers, such as [Naked Browser](https://play.google.com/store/apps/details?id=com.fevdev.nakedbrowser https://play.google.com/store/apps/details?id=com.fevdev.nak...) and [Via](https://play.google.com/store/apps/details?id=mark.via.gp&hl=en https://play.google.com/store/apps/details?id=mark.via.gp&hl...) *correction, according to https://developer.chrome.com/multidevice/webview/overview https://developer.chrome.com/multidevice/webview/overview they are still separate, it references android L dev preview so not the latest source tho...
- tomgaga 6y ago
  Actually, you can select which Chrome to use for the Webview in Android developer settings if you have Installed multiple versions of Chrome. Chrome stands on its own.
- tbodt 6y ago
  I measured Trichrome, which is the separate APK where the actual rendering engine is stored.
arghwhat 6y ago
So Chrome for Android is 10MB larger than the entirety of Damn Small Linux, which includes a desktop environment with three web browsers (firefox, dillo and netrik). 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.
- anthk 6y ago
  >Large binaries are slow binaries. False. Loop unrolling is always faster.
  - JoeAltmaier 6y ago
    Depends largely on the state of code caches, microcode and bus structure. Loop unrolling can be the worst thing you can do, on some architectures. 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.
  - arghwhat 6y ago
    > 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.
- tbodt 6y ago
  Firefox on my mac is over 200MB. Is it smaller on Damn Small Linux? 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.

by tbodt 6y ago

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.

jan6 6y ago

I'm preeettty sure that's just because it's relying on the separate WebView app, using WebView is also how it's possible for people to make sub-megabyte android browsers, such as [Naked Browser](https://play.google.com/store/apps/details?id=com.fevdev.nakedbrowser https://play.google.com/store/apps/details?id=com.fevdev.nak...) and [Via](https://play.google.com/store/apps/details?id=mark.via.gp&hl=en https://play.google.com/store/apps/details?id=mark.via.gp&hl...) *correction, according to https://developer.chrome.com/multidevice/webview/overview https://developer.chrome.com/multidevice/webview/overview they are still separate, it references android L dev preview so not the latest source tho...

tomgaga 6y ago
Actually, you can select which Chrome to use for the Webview in Android developer settings if you have Installed multiple versions of Chrome. Chrome stands on its own.
tbodt 6y ago
I measured Trichrome, which is the separate APK where the actual rendering engine is stored.

arghwhat 6y ago

So Chrome for Android is 10MB larger than the entirety of Damn Small Linux, which includes a desktop environment with three web browsers (firefox, dillo and netrik). 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.

anthk 6y ago
>Large binaries are slow binaries. False. Loop unrolling is always faster.
- JoeAltmaier 6y ago
  Depends largely on the state of code caches, microcode and bus structure. Loop unrolling can be the worst thing you can do, on some architectures. 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.
- arghwhat 6y ago
  > 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.
tbodt 6y ago
Firefox on my mac is over 200MB. Is it smaller on Damn Small Linux? 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.