Executable size is big, data segment count is > 100k

[dfordivam]

The blocking issue here is: due to the large number of data segments the Firefox does not run the wasm executable (though it can if its internal limit is increased).

Also the size of exe is very large. Here is a comparison table of sizes (in mb) of jsaddle app

Target	size	strip	gzip
Wasm	27	22	3.5
Linux (Native)	2.0	1.5	0.42
Linux (Native) (no gc)	32	-	-
Linux (Unreg)	56	43	7.3
Linux (Unreg) -split-sections	28	22	3.7

So this clearly shows that we are at par with the linux unregistered version. Also if we disable --gc-sections in wasm, then the exe size is 54mb. Wasm linker seems to be doing aggressive --gc-sections by default, even without the -split-sections fix ( as discussed in WebGHC/ghc#13)

The --gc-sections does ~10x size reduction in native exe, and only 2x in unregistered. So it seems we do have some margin of improvement here...

For stripping debug data from wasm (ie remove custom sections), I used this utility https://github.com/dfordivam/wasm-optimize

Also the gzipped version of wasm exe is quite small, indicating that there is a lot of similar/duplicate stuff.

[dfordivam]

Some data on the symbols count

Got this data from objdump | grep jsaddle/aeson

The first count is the non-gc-sections exe, second is with gc-sections.

Pkg	Native	Unreg	Wasm
aeson	6k/332	8.4k/8.4k	8.4k/5.7k
jsaddle	4k/797	5.2k/5.2k	4.8k/3k

Clearly the wasm --gc-sections is doing better than unregistered linux, but is still quite bad compared to native.