Minimize the number of IIFEs generated by Desugar for Closure IR nodes #2675

Atry · 2016-12-05T06:48:45Z

Was: Scala.js with Scala 2.12.0 creates too many unnecessary IIFE

I created a web framework Binding.scala, which generates deeply nested blocks for XHTML literal.

These kind of blocks will be converted to IIFE for ECMAScript 5 like this:

                              x(function(a, b, c) {
                                return function(e) {
                                  var f = B();
                                  return S((new G).d(P(C(new D, function(a) {
                                    return function() {
                                      return (new G).d(P(C(new D, function() {
                                        return function() {
                                          return (new F).g(U(Q(), "\n        "));
                                        };
                                      }(a))));
                                    };
                                  }(a, f)))), x(function(a, b, c, e) {
                                    return function(b) {
                                      return E((new G).d(P(C(new D, function(a) {
                                        return function() {
                                          return x(function() {
                                            return function(a) {
                                              return a;
                                            };
                                          }(a));
                                        };
                                      }(a)))), x(function(a, b, c, e) {
                                        return function(a) {
                                          var f = (new F).g((new J).n([b, c, e]));
                                          return (new Eb).Y((new Fb).Y(f, a), x(function() {
                                            return function(a) {
                                              return a;
                                            };
                                          }(f)));
                                        };
                                      }(a, c, e, b)));
                                    };
                                  }(a, b, c, e)));
                                };
                              }(a, b, c))

The entire JS file can be found at https://github.com/ThoughtWorksInc/todo/blob/3f173cd/js/js-opt.js

These IIFEs are very slow. In some benchmarks, even the output ECMAScript 2015 code (which creates const instead of IIFE) with fast optimizer runs two times faster than ECMAScript 5 code with full optimizer!

I expect that Closure Compiler would inline IIFE, or enabling Closure Compiler for ECMAScript 2015.

sjrd · 2016-12-05T07:13:46Z

I don't really understand what you want Scala.js to do here? Could you make that more precise? We don't develop Closure, so changing what it does is not within our ability.

sjrd · 2016-12-05T07:15:11Z

It's also not clear to me what "the ECMAScript 2015" code is. Generated how, by what, from what?

Atry · 2016-12-05T07:20:49Z

I mean some benchmarks run faster with the option scalaJSOutputMode := org.scalajs.core.tools.linker.backend.OutputMode.ECMAScript6 than the default setting, even if the previous setting disables Closure Compiler. I guess the reason is that OutputMode.ECMAScript6 avoids IIFE.

I noticed that Closure Compiler supports ECMAScript 2015 input format. I wonder if we could enable Closure Compiler for OutputMode.ECMAScript6, so that the output JavaScript would eliminate IIFE along with other optimizations from the Closure Compiler.

sjrd · 2016-12-05T07:30:11Z

I guess the reason is that OutputMode.ECMAScript6 avoids IIFE.

It doesn't, so that's not the actual reason.

The actual reason is that Closure typically degrades performance a bit, up to 50% in some of our benchmarks. If you want to fairly compare the ES5 version versus ES2015, you should either compare their fastOpt variants, or explicitly disable Closure in fullOpt for ES5.

That said, we should indeed enable Closure in the ES2015 output now that it supports it.

Atry · 2016-12-05T07:38:05Z

@sjrd I re-checked the ECMAScript 2015 output. You are right, there are many IIFEs in the output.

I used to think that ECMAScript 2015 target does not use IIFE in favor of const and let.

Atry · 2016-12-05T07:45:58Z

AFAIK, the Scala.js compiler inline regular functions, however, it brings more IIFE function calls.
I wonder what the purpose is for so many IIFEs.

sjrd · 2016-12-05T07:55:07Z

In general, they are necessary so that captures are truly immutable (and not a read-only version of a variable whose value changes in each iteration of a loop). Not all of them are necessary. A more sophisticated translation in JSDesugaring could avoid some of them. I have never done so because I lack proper macro benchmarks doing lots of anonymous functions to evaluate the changes.

Atry · 2016-12-05T07:59:06Z

I noticed that Scala 2.11.x does not create IIFEs (creating prototype classes instead), and has better performance for most cases than Scala 2.12.x.
FYI.

Atry · 2016-12-07T03:57:33Z

The result of the benchmark can be found at https://atry.github.io/scala-js/table.html , and the source code is at https://github.com/krausest/js-framework-benchmark

You may notice that Scala 2.12 is slower than 2.11 for almost every benchmark and consumes 122% memory comparing to Scala 2.11 version.

sjrd · 2016-12-07T10:38:10Z

Could you also benchmark with 2.11 with the -Ydelambdafy:method flag? It should cause 2.11 to emit lambdas using a scheme closer to what 2.12 does. That would give more insight on whether it is the lambda encoding's fault or something else in 2.12.

Atry · 2016-12-07T10:52:46Z

Yes, Scala 2.11 with -Ydelambdafy:method yields the same result as Scala 2.12

sjrd · 2016-12-07T10:57:21Z

Thanks. I guess it would be worth trying to improve the emitter about that, then.

Atry · 2016-12-29T09:59:30Z

@sjrd , As long as Closure compiler supports ECMAScript 6 input, which allows scoped let and const, is it possible to not generate any IIFE at all?

sjrd · 2016-12-29T10:06:42Z

With the ECMAScript6 output mode, yes.

gzm0 · 2020-05-04T06:57:20Z

Is this still an issue? My understanding of the discussion is that using ES6 entirely mitigates the need for this.

@sjrd This had me toying with the idea of always generating ES6 when using closure and have closure compile ES6 down to ES5.1.

This would:

Probably give some shorter code to ES5 users in fullOptJS
Let us remove the javascript.Trees.DocComment tree.

WDYT?


        Always use ES6 internally when using closure

In turn, we configure closure to compile ES6 down to ES5. This gives closure more structured information about the relevant trees. As a side-effect, this fixes scala-js#2675.


        Always use ES6 internally when using closure

In turn, we configure closure to compile ES6 down to ES5. This gives closure more structured information about the relevant trees. As a side-effect, this fixes scala-js#2675.


        Always use ES6 internally when using closure

In turn, we configure closure to compile ES6 down to ES5. This gives closure more structured information about the relevant trees. As a side-effect, this fixes scala-js#2675.

sjrd · 2020-05-04T10:22:45Z

Is this still an issue? My understanding of the discussion is that using ES6 entirely mitigates the need for this.

ES6 has the features that would allow us not to generate IIFEs, but we don't leverage them.

This had me toying with the idea of always generating ES6 when using closure and have closure compile ES6 down to ES5.1.

This would:
* Probably give some shorter code to ES5 users in fullOptJS
* Let us remove the `javascript.Trees.DocComment` tree.
WDYT?

In general, one cannot compile down ES 2015 semantics entirely accurately to ES 5.1. There are choices involved, and not all compilers agree. We cannot guarantee that GCC makes the same choices (and will continue to make the same choices) regarding the particular semantics to give to things that do not have an exact equivalent in ES 5.1. Therefore I think that giving ES 2015 to GCC while we give ES 5.1 in fastOpt would be dangerous. We could leave things go unchecked/broken in production mode.

Atry changed the title ~~Closure Compiler does not properly inline IIFE~~ Scala.js with Scala 2.12.0 creates too many unnecessary IIFE Dec 6, 2016

sjrd changed the title ~~Scala.js with Scala 2.12.0 creates too many unnecessary IIFE~~ Minimize the number of IIFEs generated by Desugar for Closure IR nodes Dec 7, 2016

sjrd added the optimization label Dec 7, 2016

sjrd added this to the Post-v1.0.0 milestone Oct 11, 2017

Atry mentioned this issue Nov 18, 2017

Enable GCC for OutputMode.ECMAScript2015 #3181

Closed

Atry mentioned this issue May 24, 2018

Finish the refactoring of `OutputMode` into `ESFeatures`. #3308

Merged

gzm0 removed this from the Post-v1.0.0 milestone Apr 8, 2020

gzm0 mentioned this issue May 4, 2020

Always use ES6 as intermediary closure input #4032

Closed

Aug	SEP	Oct
	08
2019	2020	2021

scala-js / scala-js

Minimize the number of IIFEs generated by Desugar for Closure IR nodes #2675

Minimize the number of IIFEs generated by Desugar for Closure IR nodes #2675

Atry commented Dec 5, 2016 •

edited by sjrd

sjrd commented Dec 5, 2016

sjrd commented Dec 5, 2016

Atry commented Dec 5, 2016 •

edited

sjrd commented Dec 5, 2016

Atry commented Dec 5, 2016

Atry commented Dec 5, 2016

sjrd commented Dec 5, 2016

Atry commented Dec 5, 2016

Atry commented Dec 7, 2016 •

edited

sjrd commented Dec 7, 2016

Atry commented Dec 7, 2016

sjrd commented Dec 7, 2016

Atry commented Dec 29, 2016

sjrd commented Dec 29, 2016

gzm0 commented May 4, 2020

sjrd commented May 4, 2020

scala-js / scala-js

Join GitHub today

Minimize the number of IIFEs generated by Desugar for Closure IR nodes #2675

Minimize the number of IIFEs generated by Desugar for Closure IR nodes #2675

Comments

Atry commented Dec 5, 2016 • edited by sjrd

sjrd commented Dec 5, 2016

sjrd commented Dec 5, 2016

Atry commented Dec 5, 2016 • edited

sjrd commented Dec 5, 2016

Atry commented Dec 5, 2016

Atry commented Dec 5, 2016

sjrd commented Dec 5, 2016

Atry commented Dec 5, 2016

Atry commented Dec 7, 2016 • edited

sjrd commented Dec 7, 2016

Atry commented Dec 7, 2016

sjrd commented Dec 7, 2016

Atry commented Dec 29, 2016

sjrd commented Dec 29, 2016

gzm0 commented May 4, 2020

sjrd commented May 4, 2020

Atry commented Dec 5, 2016 •

edited by sjrd

Atry commented Dec 5, 2016 •

edited

Atry commented Dec 7, 2016 •

edited