Faster, smaller wasm runtime - #51446

Closed
benaadams wants to merge 2 commits into
dotnet:mainfrom
benaadams:wasm-runtime
Closed

Faster, smaller wasm runtime#51446
benaadams wants to merge 2 commits into
dotnet:mainfrom
benaadams:wasm-runtime

Conversation

@benaadams

@benaadamsbenaadams commented Apr 17, 2021•
edited
Loading

Copy link
Copy Markdown
Member
  • 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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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

@ghost

ghost commented Apr 17, 2021

Copy link
Copy Markdown

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

omariom commented Apr 17, 2021

Copy link
Copy Markdown
Contributor

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

Just create a dedicated benaadams label already!

@danmoseleydanmoseley added the size-reduction Issues impacting final app size primary for size sensitive workloads label Apr 17, 2021
@ghost

ghost commented Apr 17, 2021

Copy link
Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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

ghost commented Apr 17, 2021

Copy link
Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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:-

@benaadamsbenaadams reopened this Apr 17, 2021
@ghost

ghost commented Apr 17, 2021

Copy link
Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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

CoffeeFlux commented Apr 17, 2021•
edited
Loading

Copy link
Copy Markdown
Contributor

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.

@danmoseleydanmoseley added the tenet-performance Performance related issue label Apr 17, 2021
@benaadams

benaadams commented Apr 18, 2021

Copy link
Copy Markdown
MemberAuthor

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

@benaadamsbenaadams mentioned this pull request Apr 18, 2021
Closed
@benaadams

benaadams commented Apr 18, 2021

Copy link
Copy Markdown
MemberAuthor

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

eerhardt commented Apr 19, 2021

Copy link
Copy Markdown
Member

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)

@runfoapprunfoappBot mentioned this pull request Apr 19, 2021
Closed
@CoffeeFluxCoffeeFlux mentioned this pull request Apr 19, 2021
Open
@ghostghost locked as resolved and limited conversation to collaborators May 19, 2021
@karelzkarelz added this to the 6.0.0 milestone May 20, 2021
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@marek-safarmarek-safarAwaiting requested review from marek-safar

Assignees

No one assigned

Labels

arch-wasmWebAssembly architecturearea-Build-monosize-reductionIssues impacting final app size primary for size sensitive workloadstenet-performancePerformance related issue

Projects

None yet

Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@benaadams@omariom@CoffeeFlux@eerhardt@karelz@danmoseley
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Faster, smaller wasm runtime - #51446
Closed
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Closed
Faster, smaller wasm runtime#51446
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Conversation
@benaadams
@benaadamsbenaadams
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Member
  • 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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
omariom
commented
Apr 17, 2021

Copy link


Copy Markdown

Contributor
I couldn't figure out the best area label to add to this PR.
Just create a dedicated benaadams label already!
@danmoseleydanmoseley
added
the 
size-reduction
Issues impacting final app size primary for size sensitive workloads
label
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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:-
@benaadamsbenaadams
reopened this
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
CoffeeFlux
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Contributor
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.
@danmoseleydanmoseley
added
the 
tenet-performance
Performance related issue
label
Apr 17, 2021
@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
@benaadamsbenaadams
mentioned this pull request
Apr 18, 2021
 Closed

@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
eerhardt
commented
Apr 19, 2021

Copy link


Copy Markdown

Member
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)
@runfoapprunfoappBot
mentioned this pull request
Apr 19, 2021

Closed

@CoffeeFluxCoffeeFlux
mentioned this pull request
Apr 19, 2021

Open

@ghostghost
locked as resolved and limited conversation to collaborators
May 19, 2021
@karelzkarelz
added this to the 6.0.0 milestone
May 20, 2021
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@marek-safarmarek-safarAwaiting requested review from marek-safar

Assignees


No one assigned


Labels

arch-wasmWebAssembly architecturearea-Build-monosize-reductionIssues impacting final app size primary for size sensitive workloadstenet-performancePerformance related issue

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@benaadams@omariom@CoffeeFlux@eerhardt@karelz@danmoseley

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Faster, smaller wasm runtime - #51446
Closed
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Closed
Faster, smaller wasm runtime#51446
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Conversation
@benaadams
@benaadamsbenaadams
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Member
  • 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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
omariom
commented
Apr 17, 2021

Copy link


Copy Markdown

Contributor
I couldn't figure out the best area label to add to this PR.
Just create a dedicated benaadams label already!
@danmoseleydanmoseley
added
the 
size-reduction
Issues impacting final app size primary for size sensitive workloads
label
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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:-
@benaadamsbenaadams
reopened this
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
CoffeeFlux
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Contributor
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.
@danmoseleydanmoseley
added
the 
tenet-performance
Performance related issue
label
Apr 17, 2021
@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
@benaadamsbenaadams
mentioned this pull request
Apr 18, 2021
 Closed

@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
eerhardt
commented
Apr 19, 2021

Copy link


Copy Markdown

Member
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)
@runfoapprunfoappBot
mentioned this pull request
Apr 19, 2021

Closed

@CoffeeFluxCoffeeFlux
mentioned this pull request
Apr 19, 2021

Open

@ghostghost
locked as resolved and limited conversation to collaborators
May 19, 2021
@karelzkarelz
added this to the 6.0.0 milestone
May 20, 2021
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@marek-safarmarek-safarAwaiting requested review from marek-safar

Assignees


No one assigned


Labels

arch-wasmWebAssembly architecturearea-Build-monosize-reductionIssues impacting final app size primary for size sensitive workloadstenet-performancePerformance related issue

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@benaadams@omariom@CoffeeFlux@eerhardt@karelz@danmoseley

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Faster, smaller wasm runtime - #51446
Closed
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Closed
Faster, smaller wasm runtime#51446
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Conversation
@benaadams
@benaadamsbenaadams
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Member
  • 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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
omariom
commented
Apr 17, 2021

Copy link


Copy Markdown

Contributor
I couldn't figure out the best area label to add to this PR.
Just create a dedicated benaadams label already!
@danmoseleydanmoseley
added
the 
size-reduction
Issues impacting final app size primary for size sensitive workloads
label
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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:-
@benaadamsbenaadams
reopened this
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
CoffeeFlux
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Contributor
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.
@danmoseleydanmoseley
added
the 
tenet-performance
Performance related issue
label
Apr 17, 2021
@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
@benaadamsbenaadams
mentioned this pull request
Apr 18, 2021
 Closed

@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
eerhardt
commented
Apr 19, 2021

Copy link


Copy Markdown

Member
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)
@runfoapprunfoappBot
mentioned this pull request
Apr 19, 2021

Closed

@CoffeeFluxCoffeeFlux
mentioned this pull request
Apr 19, 2021

Open

@ghostghost
locked as resolved and limited conversation to collaborators
May 19, 2021
@karelzkarelz
added this to the 6.0.0 milestone
May 20, 2021
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@marek-safarmarek-safarAwaiting requested review from marek-safar

Assignees


No one assigned


Labels

arch-wasmWebAssembly architecturearea-Build-monosize-reductionIssues impacting final app size primary for size sensitive workloadstenet-performancePerformance related issue

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@benaadams@omariom@CoffeeFlux@eerhardt@karelz@danmoseley

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Faster, smaller wasm runtime - #51446
Closed
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Closed
Faster, smaller wasm runtime#51446
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Conversation
@benaadams
@benaadamsbenaadams
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Member
  • 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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
omariom
commented
Apr 17, 2021

Copy link


Copy Markdown

Contributor
I couldn't figure out the best area label to add to this PR.
Just create a dedicated benaadams label already!
@danmoseleydanmoseley
added
the 
size-reduction
Issues impacting final app size primary for size sensitive workloads
label
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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:-
@benaadamsbenaadams
reopened this
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
CoffeeFlux
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Contributor
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.
@danmoseleydanmoseley
added
the 
tenet-performance
Performance related issue
label
Apr 17, 2021
@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
@benaadamsbenaadams
mentioned this pull request
Apr 18, 2021
 Closed

@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
eerhardt
commented
Apr 19, 2021

Copy link


Copy Markdown

Member
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)
@runfoapprunfoappBot
mentioned this pull request
Apr 19, 2021

Closed

@CoffeeFluxCoffeeFlux
mentioned this pull request
Apr 19, 2021

Open

@ghostghost
locked as resolved and limited conversation to collaborators
May 19, 2021
@karelzkarelz
added this to the 6.0.0 milestone
May 20, 2021
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@marek-safarmarek-safarAwaiting requested review from marek-safar

Assignees


No one assigned


Labels

arch-wasmWebAssembly architecturearea-Build-monosize-reductionIssues impacting final app size primary for size sensitive workloadstenet-performancePerformance related issue

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@benaadams@omariom@CoffeeFlux@eerhardt@karelz@danmoseley

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Faster, smaller wasm runtime - #51446
Closed
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Closed
Faster, smaller wasm runtime#51446
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Conversation
@benaadams
@benaadamsbenaadams
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Member
  • 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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
omariom
commented
Apr 17, 2021

Copy link


Copy Markdown

Contributor
I couldn't figure out the best area label to add to this PR.
Just create a dedicated benaadams label already!
@danmoseleydanmoseley
added
the 
size-reduction
Issues impacting final app size primary for size sensitive workloads
label
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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:-
@benaadamsbenaadams
reopened this
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
CoffeeFlux
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Contributor
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.
@danmoseleydanmoseley
added
the 
tenet-performance
Performance related issue
label
Apr 17, 2021
@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
@benaadamsbenaadams
mentioned this pull request
Apr 18, 2021
 Closed

@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
eerhardt
commented
Apr 19, 2021

Copy link


Copy Markdown

Member
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)
@runfoapprunfoappBot
mentioned this pull request
Apr 19, 2021

Closed

@CoffeeFluxCoffeeFlux
mentioned this pull request
Apr 19, 2021

Open

@ghostghost
locked as resolved and limited conversation to collaborators
May 19, 2021
@karelzkarelz
added this to the 6.0.0 milestone
May 20, 2021
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@marek-safarmarek-safarAwaiting requested review from marek-safar

Assignees


No one assigned


Labels

arch-wasmWebAssembly architecturearea-Build-monosize-reductionIssues impacting final app size primary for size sensitive workloadstenet-performancePerformance related issue

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@benaadams@omariom@CoffeeFlux@eerhardt@karelz@danmoseley

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Faster, smaller wasm runtime - #51446
Closed
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Closed
Faster, smaller wasm runtime#51446
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Conversation
@benaadams
@benaadamsbenaadams
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Member
  • 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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
omariom
commented
Apr 17, 2021

Copy link


Copy Markdown

Contributor
I couldn't figure out the best area label to add to this PR.
Just create a dedicated benaadams label already!
@danmoseleydanmoseley
added
the 
size-reduction
Issues impacting final app size primary for size sensitive workloads
label
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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:-
@benaadamsbenaadams
reopened this
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
CoffeeFlux
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Contributor
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.
@danmoseleydanmoseley
added
the 
tenet-performance
Performance related issue
label
Apr 17, 2021
@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
@benaadamsbenaadams
mentioned this pull request
Apr 18, 2021
 Closed

@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
eerhardt
commented
Apr 19, 2021

Copy link


Copy Markdown

Member
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)
@runfoapprunfoappBot
mentioned this pull request
Apr 19, 2021

Closed

@CoffeeFluxCoffeeFlux
mentioned this pull request
Apr 19, 2021

Open

@ghostghost
locked as resolved and limited conversation to collaborators
May 19, 2021
@karelzkarelz
added this to the 6.0.0 milestone
May 20, 2021
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@marek-safarmarek-safarAwaiting requested review from marek-safar

Assignees


No one assigned


Labels

arch-wasmWebAssembly architecturearea-Build-monosize-reductionIssues impacting final app size primary for size sensitive workloadstenet-performancePerformance related issue

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@benaadams@omariom@CoffeeFlux@eerhardt@karelz@danmoseley

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Faster, smaller wasm runtime - #51446
Closed
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Closed
Faster, smaller wasm runtime#51446
benaadams wants to merge 2 commits into
dotnet:mainfrom 
benaadams:wasm-runtime
Conversation
@benaadams
@benaadamsbenaadams
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Member
  • 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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
omariom
commented
Apr 17, 2021

Copy link


Copy Markdown

Contributor
I couldn't figure out the best area label to add to this PR.
Just create a dedicated benaadams label already!
@danmoseleydanmoseley
added
the 
size-reduction
Issues impacting final app size primary for size sensitive workloads
label
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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:-
@benaadamsbenaadams
reopened this
Apr 17, 2021
@ghost
ghost
commented
Apr 17, 2021

Copy link


Copy Markdown

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
FileBranchUncompressedBrotli
dotnet.jsmain242 KB51 KB
dotnet.jsPR123 KB36 KB
dotnet.wasmmain2,220 KB764 KB
dotnet.wasmPR2,338 KB771 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
CoffeeFlux
commented
Apr 17, 2021•

edited

Loading

Copy link


Copy Markdown

Contributor
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.
@danmoseleydanmoseley
added
the 
tenet-performance
Performance related issue
label
Apr 17, 2021
@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
@benaadamsbenaadams
mentioned this pull request
Apr 18, 2021
 Closed

@benaadams
benaadams
commented
Apr 18, 2021

Copy link


Copy Markdown

MemberAuthor
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
eerhardt
commented
Apr 19, 2021

Copy link


Copy Markdown

Member
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)
@runfoapprunfoappBot
mentioned this pull request
Apr 19, 2021

Closed

@CoffeeFluxCoffeeFlux
mentioned this pull request
Apr 19, 2021

Open

@ghostghost
locked as resolved and limited conversation to collaborators
May 19, 2021
@karelzkarelz
added this to the 6.0.0 milestone
May 20, 2021
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@marek-safarmarek-safarAwaiting requested review from marek-safar

Assignees


No one assigned


Labels

arch-wasmWebAssembly architecturearea-Build-monosize-reductionIssues impacting final app size primary for size sensitive workloadstenet-performancePerformance related issue

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@benaadams@omariom@CoffeeFlux@eerhardt@karelz@danmoseley