Alternative production code generation for AMP based on the closure compiler #1218
Conversation
cramforce
commented
Dec 22, 2015
cramforce
commented
- Currently a 15K win on main binary and likely much faster initial JS compilation due to simpler code.
- Includes a compiled compiler binary while we wait for a patch to land that is needed to compiler core-js.
- Doesn't yet activate (and benefit in code size) from type checking.
| @@ -434,7 +434,7 @@ export class Viewer { | |||
| * @param {boolean} awaitResponse | |||
| * @return {(!Promise<*>|undefined)} | |||
| * @package | |||
| * @export | |||
| * _export | |||
There was a problem hiding this comment.
We do manual exports practically for everything else. So, we could do the same here.
There was a problem hiding this comment.
There is no magic here anyway. For a long time we won't be able to run with property obfuscation anyway.
cramforce
force-pushed
the
cc
branch
2 times, most recently
from
4f50961
to
bc388c8
Compare
|
@erwinmombay I ported this based on your change to use gulp for the compiler invocation. And bundled a compiled compiler that has my patch with the PR. The nice thing: The generated code actually works :) Makes compiled code 15KB smaller. 3KB after GZip. This is with simple optimizations only. |
|
@cramforce thats awesome to hear! |
cramforce
changed the title
|
@erwinmombay Updated version. Major win: I was able to get rid of listing the core-js files individually. Had to set a flag that was also otherwise important :) I think we should submit this and then work from there to transform the rest of the code gen. |
- Currently a 15K win on main binary and likely much faster initial JS compilation due to simpler code. - Includes a compiled compiler binary while we wait for a patch to land that is needed to compiler core-js. - Doesn't yet activate (and benefit in code size) from type checking.
|
@cramforce LGTM. |
Alternative production code generation for AMP based on the closure compiler
