Faster, smaller wasm runtime

[benaadams]

• Compile the wasm using -O3 rather than -Oz for a faster runtime
• Use the closure compiler to bring down the size of the .js to make up the difference in filesize

File	Branch	Uncompressed	Brotli
dotnet.js	main	242 KB	51 KB
dotnet.js	PR	123 KB	36 KB
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB
Net Change		-1 KB	-22 KB

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[omariom]

I couldn't figure out the best area label to add to this PR.

Just create a dedicated benaadams label already!

[ghost]

Tagging subscribers to 'size-reduction': @eerhardt, @SamMonoRT, @marek-safar, @CoffeeFlux
See info in area-owners.md if you want to be subscribed.

Issue Details

---

• Compile the wasm using -O3 rather than -Oz for a faster runtime
• Use the closure compiler to bring down the size of the .js to make up the difference in filesize

File	Branch	Uncompressed	Brotli
dotnet.js	main	242 KB	51 KB
dotnet.js	PR	123 KB	36 KB
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB
Net Change		-1 KB	-22 KB

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

Author:	benaadams
Assignees:	-
Labels:	size-reduction
Milestone:	-

[ghost]

Tagging subscribers to this area: @directhex
See info in area-owners.md if you want to be subscribed.

Issue Details

---

• Compile the wasm using -O3 rather than -Oz for a faster runtime
• Use the closure compiler to bring down the size of the .js to make up the difference in filesize

File	Branch	Uncompressed	Brotli
dotnet.js	main	242 KB	51 KB
dotnet.js	PR	123 KB	36 KB
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB
Net Change		-1 KB	-22 KB

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

Author:	benaadams
Assignees:	-
Labels:	area-Infrastructure-mono, size-reduction
Milestone:	-

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

• Compile the wasm using -O3 rather than -Oz for a faster runtime
• Use the closure compiler to bring down the size of the .js to make up the difference in filesize

File	Branch	Uncompressed	Brotli
dotnet.js	main	242 KB	51 KB
dotnet.js	PR	123 KB	36 KB
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB
Net Change		-1 KB	-22 KB

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

Author:	benaadams
Assignees:	-
Labels:	arch-wasm, area-Build-mono, size-reduction
Milestone:	-

[CoffeeFlux]

Huh, I thought we were already running the closure compiler... I wonder what happened there. Regardless, thanks a bunch for catching that! That's a really nice win on size.

Regarding the Oz to O3 change, there has been a fair bit of discussion about this internally. I'd personally like to see another benchmark run to get an idea of the tradeoff here, but ultimately it's up to @lewing. 7K isn't too bad a penalty to pay though, so I think it's worth considering.

[benaadams]

Might split this into different bits as the clousre compiler on ADVANCED_OPTIMIZATIONS needs lots of externs setting up or outside callers (like Blazor) end up with lots of "undefined not a function" as the names are garbled

[benaadams]

Opened issue for the -O3 at #51458; not sure how to benchmark it; also has the groundwork for the closure compiler on 1; but too much to verify upstream to easily switch that on

[eerhardt]

build-native: $(NATIVE_BIN_DIR)/dotnet.js $(NATIVE_BIN_DIR)/src/emcc-flags.txt $(NATIVE_BIN_DIR)/src/emcc-version.txt

Is this supposed to get --externs runtime/externs.js on it?

This is pre-existing to your change, but it seems like this Makefile and the wasm.proj are duplicated. Is that intentional?

---

Refers to: src/mono/wasm/Makefile:125 in 9113bc9. [](commit_id = 9113bc9, deletion_comment = False)