You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This transformation can be done only when the following two criteria are met:
The creation of future2 doesn't depend on the result of future1; and,
The evaluation of the value of future1 doesn't influence the evaluation of getSomeFuture2 and future2.
This manual transformation is quite tedious. This transformation is pretty mechanical and therefore ideally suited for a macro or compiler optimisation. Also, we need to a way to verify the two conditions hold, unless we leave that to the developer.
The reason why I suggest performing the transformation on the level of futures instead of await/async is so it can be used in more scenarios.
The text was updated successfully, but these errors were encountered:
Also, we need to a way to verify the two conditions hold, unless we leave that to the developer.
The compiler won't be able to help out here, we don't have any framework for purity analysis.
But I think it would be okay to have an Async.asyncAggressive alternative entry point to let the developer opt in to the reordering. (Or maybe AsyncAggressive.async).
To start experimenting with this, you could create AsyncAggressive in the same way that Async is constructed, customizing postAnfTransform to perform the reordering.
[async] ANF transform expands to:
{
();
val awaitable$macro$2 = f;
val await$macro$3 = scala.async.Async.await[Int](awaitable$macro$2);
val awaitable$macro$4 = f;
val await$macro$5 = scala.async.Async.await[Int](awaitable$macro$4);
val x$macro$6 = await$macro$5;
await$macro$3.+(x$macro$6)
}
The new transform would then kick in and result in:
[async] Reordering transform expands to:
{
();
val awaitable$macro$2 = f;
val awaitable$macro$4 = f;
val await$macro$3 = scala.async.Async.await[Int](awaitable$macro$2);
val await$macro$5 = scala.async.Async.await[Int](awaitable$macro$4);
val x$macro$6 = await$macro$5;
await$macro$3.+(x$macro$6)
}
It is a well known issue with for-comprehensions where the futures in the code block below are not executed as parallel as possible:
We can manually solve this by rewriting the code as the code block:
This transformation can be done only when the following two criteria are met:
This manual transformation is quite tedious. This transformation is pretty mechanical and therefore ideally suited for a macro or compiler optimisation. Also, we need to a way to verify the two conditions hold, unless we leave that to the developer.
The reason why I suggest performing the transformation on the level of futures instead of await/async is so it can be used in more scenarios.
The text was updated successfully, but these errors were encountered: