←back to thread

239 points ivankra | 1 comments | | HN request time: 0.241s | source
Show context
bcardarella ◴[] No.45945551[source]
Just a small comparison, compiled for release:

Boa: 23M Brimstone: 6.3M

I don't know if closing the gap on features with Boa and hardening for production use will also bloat the compilation size. Regardless, for passing 97% of the spec at this size is pretty impressive.

replies(3): >>45945705 #>>45945748 #>>45950091 #
jerf ◴[] No.45945748[source]
It looks like Boa has Unicode tables compiled inside of itself: https://github.com/boa-dev/boa/tree/main/core/icu_provider

Brimstone does not appear to.

That covers the vast bulk of the difference. The ICU data is about 10.7MB in the source (boa/core/icu_provider) and may grow or shrink by some amount in the compiling.

I'm not saying it's all the difference, just the bulk.

There's a few reasons why svelte little executables with small library backings aren't possible anymore, and it isn't just ambient undefined "bloat". Unicode is a big one. Correct handling of unicode involves megabytes of tables and data that have to live somewhere, whether it's a linked library, compiled in, tables on disks, whatever. If a program touches text and it needs to handle it correctly rather than just passing it through, there's a minimum size for that now.

replies(6): >>45945844 #>>45945976 #>>45946210 #>>45947165 #>>45947379 #>>45951653 #
1. miki123211 ◴[] No.45951653[source]
I just wish we could use system tables for that, instead of bloating every executable with their own outdated copy.

I have no issue with my system using an extra 10mb for Ancient Egyptian capitalization to work correctly. Every single program including those rules is a lot more wasteful.