I would like to see better JS support, but the scope of JS is simply insane for such a small browser. It's unfortunate much of the web is completely unusable without running JS. Perhaps it's possible to first run the page through a larger browser engine and then send the processed content to the small browser (such as Dillo), that would massively widen the scope of what it could display.
>But the scope of JS is simply insane for such a small browser.
Edbrowse has JS support thanks to duktape.
Here? https://hg.dillo.org/dillo/
Seems to be still pretty old...
> Edbrowse has JS support thanks to duktape.
Huh, very interesting: https://duktape.org/
I initially assumed by ducktape you meant "barely held together"!
*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.
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.
> Think about how much a "10 MB" only browser took up in main
> memory back in the day.
This is exactly the point, software has swelled to use the resources available to it, so with each new iteration your machine gets faster but what it runs gets slower. It doesn't feel like this is something we should settle for.