Skip to main content

dart2js now only Dart to JavaScript compiler in Editor and SDK

Posted by Seth Ladd

Today, Kasper Lund, one of Dart engineers, submitted a patch that makes dart2js the only Dart to JavaScript compiler accessible to developers. The old frog compiler will be around just a little bit longer for some legacy integrations, but it is no longer accessible via the Editor or the SDK.

In an email to the public Dart discussion list, Kasper writes:


The code that is generated by dart2js is looking better and better, but it is still a
bit too big for our liking. We're working on a few things to make it
smaller:

  * better code for logical operations
  * simpler, less nested code for switches
  * smaller code for throws
  * better bailout code

The bailout code might be of interest to some of you and I'll try to
illustrate what it is and how we plan on improving it with an example.
Given the following Dart code:

----------
  main() {
    var list = makeList();
    var sum = 0;
    for (var i = 0; i < list.length; i++) {
      sum += list[i];
    }
    print(sum);
  }


  makeList() {
    var result = new List(100);
    for (var i = 0; i < result.length; i++) {
      result[i] = i;
    }
    return result;
  }
----------

we currently generate the following JavaScript code:

----------
  $.main = function() {
    var list = $.makeList();
    if (typeof list !== 'string' &&
        (typeof list !== 'object'||list.constructor !== Array))
      return $.main$bailout(1, list);
    for (var sum = 0, i = 0; i < list.length; ) {
      var t1 = list.length;
      if (i < 0 || i >= t1) throw $.ioore(i);
      sum = $.add(sum, list[i]);
      i = i + 1;
    }
    $.print(sum);
  };


  $.makeList = function() {
    var result = $.List(100);
    for (var i = 0; i < result.length; ) {
      var t1 = result.length;
      if (i < 0 || i >= t1) throw $.ioore(i);
      result[i] = i;
      i = i + 1;
    }
    return result;
  };
----------

The code in main is a bit more involved than the code in makeList.
Inside makeList, we're sure that the list allocated is a JavaScript
array so we can use its length property and access its elements using
the [] notation. In main, we have to check that makeList actually
returned a JavaScript array (or a string) before we're sure that those
operations have the right semantics. If makeList ever returns
something that isn't a JavaScript array, we probably have to call a
user-defined length getter and operator[] for accessing the elements.
This is where the "bailout" version comes into play.

The bailout version of a method is essentially an unoptimized version
that we can jump to from the optimized version of the method. It
doesn't assume anything about its inputs and uses only generic
operations on them. We only need bailout versions for methods where we
do speculative optimizations that aren't guaranteed to be valid. The
actual code for the bailout version of main is a bit hairy:

----------
  $.main$bailout = function(state, env0) {
    switch (state) {
      case 1:
        list = env0;
        break;
    }
    switch (state) {
      case 0:
        var list = $.makeList();
      case 1:
        state = 0;
        var sum = 0;
        var i = 0;
        L0: while (true) {
          if (!$.ltB(i, $.get$length(list))) break L0;
          sum = $.add(sum, $.index(list, i));
          i = i + 1;
        }
        $.print(sum);
    }
  };
----------

Instead of using list.length and list[i], we're now calling
get$length(list) and index(list, i). The reason why the control flow
in the bailout code is so complex is that we've designed it so it is
possibly to jump into it from various parts in the optimized code.
Right now, we're not recognizing that in this case we're only
branching into it from one place (state is always one) but we plan to
make use of that to get rid of the switch and the dead code in the
unused cases.

Even though we're working on improving our support for speculative
optimizations, we're also looking into inferring concrete type
information. This would allow us to recognize the fact that makeList
always returns a JavaScript array thus eliminating the need for the
bailout version altogether. Smaller and faster code for the win.

We expect to move quickly on all of these issues -- and as always
we'll do our best to keep you guys informed about our progress!

Popular posts from this blog

Dart in 2016: The fastest growing programming language at Google, 2nd fastest growing in TIOBE Index

Dart was the fastest growing programming language at Google in 2016 with millions of lines of code written. It also made it to TIOBE Index Top 20 this month (see TIOBE's methodology).

It takes time to build something as ambitious as Dart and, in some ways, Dart is still in its infancy. But we're glad the hard work is starting to pay off.

Many thanks to our amazing community!

We're going to celebrate by ... releasing 1.22 next week (as per our usual 6 week release schedule).

A stronger Dart for everyone

We are constantly asking ourselves:
How do we make developers even more productive when writing Dart apps? We believe that a critical part of the answer to this question is to make strongmode – a sound static type system for Dart – the standard for all Dart developers.

Teams that use Dart to build apps like Soundtrap, AdWords, AdSense, and Greentea say they really enjoy using strong mode features, such as early error detection. In fact, teams that have switched completely to strong mode cite not only early error detection but also better code readability and maintainability as major benefits. We hear this both from small teams and Рeven more so Рfrom large teams with hundreds of developers writing and maintaining millions of lines of Dart code. As Björn Sperber from Soundtrap says,
Strong mode and the smooth integration with IntelliJ is a joy to use and a huge improvement. If you’ve tried out Flutter, you’ve already used strong mode checks from the Dart analyzer.

Given the benefits …

AngularDart 3.0: Easy upgrade, better performance

AngularDart 3.0 is now available. It brings better performance and smaller generated code, while also making you more productive.


Version 3.0 is an evolution: although it has some breaking changes (detailed below), it is a smooth upgrade due to minimal public API adjustments. Most of the progress is under the hood—in code quality, stability, generated code size, performance, and developer experience.

Code quality:
2731 instances of making the framework code more type safe (using sound Dart).The AngularDart framework code size is down by 12%.Many additional style updates to the codebase:Changed to use idiomatic <T> for generic methods.Removed NgZoneImpl, all the code exists in NgZone now.Stability:
Many CSS encapsulation fixes due to update with csslib package.Fixed bugs with IE11.

Performance:
For the Mail sample app, we see 30% faster time-to-interactive (currently 3812 ms on a simulated 3G connection, measured via Lighthouse).Our large app benchmark shows 2x faster render times of…