Use abbreviations for common JS symbols to save on code size

[sbc100]

I notices that there are cases where use common JavaScript symbols (e.g. Object.assign) multiple times in a single program and non of our current minification passes (including closure compiler) are able to remove or reduce the duplication of these strings.

Admittedly, gzip will can probably do a good job here, but we can't fully depend on that.

I tried creating simple change where I add common abbreviations to shell.js e.g.:

var assign = Object.assign;
..etc

However this has some downsides. Notably:

• It always includes these even if they are not used. We cannot use library dependencies here because some of the usages are in the shell itself which comes before any library symbol is included.
• The usages would all need to be changed from some thing well-known to something not well-known. This decreases maintainability and makes debugging harder. It also means that user-code that uses these symbols would need to be updated too or would not benefit.

Proposed solution: Add a new acorn optimizer pass that can find all the usages of these symbols and inject the abbreviations in the right place.

[sbc100]

@RReverser @kripken @juj, thoughts on this?

[RReverser]

Admittedly, gzip will can probably do a good job here, but we can't fully depend on that.

TBH I don't see why not. Comparing uncompressed sizes of JS/Wasm is not a very useful metric for network cost in the modern world where ~all assets are served compressed.

The only cost I can think of that cares about uncompressed sizes is JS parsing, but I doubt couple of property accesses (and only a few APIs can be replaced like this without breaking this context) would help much there.

[RReverser]

It also looks like quite a few of these Object.assign can be removed soon in favour of ES6 classes, now that ES6 usage is being unblocked.

[sbc100]

It also looks like quite a few of these Object.assign can be removed soon in favour of ES6 classes, now that ES6 usage is being unblocked.

I was just using Object.assign as an example... I'm sure there others.

[sbc100]

Admittedly, gzip will can probably do a good job here, but we can't fully depend on that.

TBH I don't see why not. Comparing uncompressed sizes of JS/Wasm is not a very useful metric for network cost in the modern world where ~all assets are served compressed.

Fair enough, would be more supportive of this feature if it were shown to save on compressed as well as uncompressed size?

[RReverser]

Fair enough, would be more supportive of this feature if it were shown to save on compressed as well as uncompressed size?

Yeah if there's substantial compressed saving then it would make sense. I'm just a bit sceptical of cost:benefit ratio particularly because most built-in methods tend to care about this context and because, as you said, gzip/brotli tend to catch these repetitive cases pretty well. Especially Brotli thanks to larger window size.

That said, I remember coming across https://github.com/emscripten-core/emscripten/issues/20022. If that's what you had in mind - somehow optimising even access to our internal namespaces - then it's more likely to be beneficial.

[kripken]

In general I think closure does this for user stuff, but maybe not for Object.assign since it can't tell if Object might be modified. Maybe closure has an option to assume no monkeypatching? Or maybe other minifiers in the ecosystem do?

[sbc100]

I think closure does nothing for builtin APIs like this.

Regarding other minifiers, I guess that is something we should look into. Perhaps run all our code size tests with several different minifiers.