the performance of async and await syntax are quite slow

[jumperchen]

Scenario

Sometimes we design an API to allow the returned value to be a Future or a Sync, which depends on its logic, so we will declare the returned value to be a Future in the function/method syntax.

For example,

foo() async {
   if (...) return 1; //sync value;
   else return new Future.value(2); // a future value
}

And then if the 'foo()' is called in a for loop for thousand� times, the async and await syntax will be the performance nightmare.

For example,

import 'dart:async';

main () async {

  // Async syntax
  var sw1 = new Stopwatch()..start();
  var count1 = 0;
  for (var i = 0; i < 10000; i++) {
    count1 += await foo();
  }
  print('Async and Await: ${sw1.elapsedMilliseconds}ms');

  // Future syntax
  var sw2 = new Stopwatch()..start();
  var count2 = 0;
  for (var i = 0; i < 10000; i++) {
    bar().then((_) {
      count2 += _;
      if (i == 9999)
        print('Future: ${sw2.elapsedMilliseconds}ms');
    });
  }

  // Sync syntax
  var sw3 = new Stopwatch()..start();
  var count3 = 0;
  for (var i = 0; i < 10000; i++) {
    count3 += baz();
  }
  print('Sync: ${sw3.elapsedMilliseconds}ms');

}

foo() async {
  return 1;
}

Future<int> bar() {
  return new Future.value(2);
}

baz() {
  return 3;
}

The result will be

Async and Await: 130ms
Sync: 0ms
Future: 79ms

An Idea

In our workaround, we implement a Sync class to extend the Future class, and by using the syntax of bar() to cheat the compiler, and it can speed up in the runtime.

For example,

Future<int>  bar() {
   if (isSync) return new Sync.value(2);
  else return new Future.value(2);
}

So it could be an idea to make this trick in Dart VM.

[jumperchen]

btw, the deferred load library can use the same trick.

For example, (in our workaround)

class FooFactory {
   static final SyncLoader syncLoader = Sync.load<bool, Foo>(wait: () => foo.loadLibrary(), then: (bool _) => new foo.Foo());
   static Future<Foo> lazyLoadFoo() {
     return syncLoader.future;
   }
 }

// usage   
FooFactory.lazyLoadFoo().then((f) => f.bar());

The result will be:
Only the first time is Future, and then all will be Sync later. (no more delay in runtime)

[lrhn]

If you just return a 1 from an async function, it will be wrapped up in a Future, so you do get the extra allocation and extra indirections in accessing the value. That's unavoidable. Asynchrony isn't free, and making a function that is called thousands of times asynchronous is going to cost. So, comparing it to a synchronous function isn't useful.

Now, comparing different asynchronous implementations is much more interesting :)

It's not surprising that latency suffers when you go to an async function. The difference between

foo() => new Future.value(42);

and

bar() async => 42;

is that the latter delays execution of the body until a later microtask. That latency is unavoidable as long as the language semantics requires that delay.

If you look at this dartpad, then dart2js doesn't really get delayed by await. It does get delayed by async - which is expected, but it's delayed more than what can be explained by a single scheduleMicrotask.

It can't explain all of the difference for the VM, though, it's await is significantly slower than the corresponding Future/then based approach.

[jumperchen]

Yes, I know that comparing Sync and Async is not fair, but in the real life it happens that we have to design an API to serve two different implementations in Sync and Async ways and only expose one public API.
It would be better if your team can come out with an official solution for us, rather than tricking with the language syntax issue to speed up. :)

[lrhn]

I agree that everything should be faster, and we are definitely not fast enough at async code yet.

That said, hiding a synchronous operation behind an async API will always have a cost. We should just try to ensure that the cost is as minimal as possible, but it won't go away.

[matanlurey]

FYI, AngularDart has requested a lint to remove all uses of async/await from our code-base:

#57714

[eernstg]

@jumperchen, here is an example showing how you can use FutureOr to abstract over the choice between synchronous and asynchronous computations:

import 'dart:async';

abstract class SyncOrAsync<X> {
  FutureOr<X> m(X x);
}

class Sync<X> implements SyncOrAsync<X> {
  X m(X x) => x;
}

class Async<X> implements SyncOrAsync<X> {
  Future<X> m(X x) async => x;
}

bool b = true; // Whatever.

main() async {
  int result;
  SyncOrAsync<int> o = b ? Sync<int>() : Async<int>();
  FutureOr<int> x = o.m(42);
  if (x is Future) {
    result = await x;
  } else {
    result = x;
  }
  print(result);
}

With FutureOr you can make the decision to return a future or a sync value dynamically, or you could make the choice as in the example (where it's dynamic when the static type of the receiver is SyncOrAsync, but statically known for receivers of type Sync and Async).

PS: It is not uncommon to recommend that FutureOr should only be used for callbacks (so myMethod(FutureOr<C> f()) is OK, but FutureOr<C> myMethod() is bad style), but the situation you're discussing here actually fits quite well. So if anyone makes that recommendation, please ignore it at least now and then. ;-)

[eernstg]

FYI, AngularDart has requested a lint to remove all uses of async/await from our code-base

@matanlurey, I'd prefer if AngularDart would put pressure on everyone (who can do something about it) to make async/await run fast. ;-)

[jumperchen]

@eernstg Yes, we had that already. (a fake future)

/**
 * A wrapper for calling the then() synchronously.
 * Support [catchError] and [whenComplete] as well.
 */
class Sync<T> implements Future<T> {
  final T raw;
  Future _error;
  dynamic _next;

  Sync.value([T v]) : this.raw = v is Sync ? v.raw : v;

  Future/*<S>*/ then /*<S>*/(onValue(T value), { Function onError }) {
    try {
      _next = Sync.resolve(onValue(raw));
      return _next;
    } catch (error, stack) {
      if (onError != null) {
        try {
          onError(error, stack);
        } catch (e, st) {
          _error = new Future.error(e, st);
          return _error as Future/*<S>*/;
        }
      }
      // simulate a future exception.
      _error = new Future.error(error, stack);
      return _error as Future/*<S>*/;
    }
  }
 static Future<T> resolve<T>(obj) {
    if (obj is Future || obj is Sync) {
      return obj;
    } else {
      return new Sync<T>.value(obj);
    }
  }
 ... // omitted

[eernstg]

@jumperchen, a fake future is in fact exactly what you don't need: With FutureOr there is no need to wrap the sync value, there is no need to have a class Sync<T> implements Future<T>, and hence you also avoid all the potential issues that you may encounter when you are using some instances whose type is Future<...>, but which are actually not futures.

[jumperchen]

@eernstg Yes, it could be but when we introduced the Sync was to get rid of the uses of async/await from our code-base, and at that time we already had 300K lines of code that we had to refactor with this issue, and we didn't want to use if/else to check whether the returned value is future or not for each API to deal with that, so we came up with this trick to save our times and it didn't break anything till now.

[matanlurey]

@eernstg:

FYI, AngularDart has requested a lint to remove all uses of async/await from our code-base

@matanlurey, I'd prefer if AngularDart would put pressure on everyone (who can do something about it) to make async/await run fast. ;-)

It's been done for years, but not been a priority for the language team (this isn't just a backend issue).

The fact that you can write:

func() async {
  return await 5;
}

... and this isn't either (a) a compile-time error or (b) just semantic sugar for:

func() {
  return new Future.value(5);
}

... makes it really difficult to optimize. And that's not even getting into the complex cases.