async block occupies twice the size of its captures (causing explosion in size).

[nolanderc]

I tried this code (playground link) which wraps a future in a trivial async block:

let foo = async move { ... };
dbg!(std::mem::size_of_val(&foo));

let bar = async move { foo.await };
dbg!(std::mem::size_of_val(&bar));

I expected to see that size_of(bar) == size_of(foo) (plus some bytes for a tag). Instead, I found that size_of(bar) > 2 * size_of(foo).

I discovered this while nesting a couple of futures which largely had the following form:

let future = function_returning_future(...);
async move { 
    let result = future.await;
    let output = /* ...do something with result... */;
    output
}

The final future occupied a few kilobytes. I was able work around this by using a map combinator, but it is not ideal.

This could possibly be related to #62958, but I'm not familiar enough with the compiler internals to say with certainty if async-block captures are implemented the same way as async fn arguments.

Meta

This happens in stable 1.67.1, beta 1.70.0, and the latest nightly.

[csmoe]

Duplicate of #59087

[pnkfelix]

Both #59087 and #62958 are relevant here. Issue #62958 talks about async fn, and part of the problems it outlines are indeed due to how async fn is desugared, but the exponential blowup you describe here is also inherent to how even async blocks and .await are desugared.

@nolanderc , do you have the capability to try out locally built branches? If so, could you give PR #108590 a whirl and see if that resolves the problematic behavior you are observing?

(We still need to resolve whether the strategy employed by #108590 is sound, given the misgivings posted on #59087 and elsewhere. But it seems to me that we will have a very fundamental problem if we cannot perform the optimization that is implemented in PR #108590.)

[nolanderc]

@pnkfelix I tried using PR #108590 by following the rustc build instructions but still see the same behaviour: the size of the futures still double for each level of nesting. Although, this is my first time building rustc from source, so I might have messed something up. Particularly, I was confused by the difference between stage1 and stage2, and which I was supposed to use, but I tried both and they gave the same results.

[pnkfelix]

@nolanderc there are still scenarios where the exponential blowup is expected. PR #108590 is only a band-aid and doesn't cover all the known cases where it can occur. (The code snippets that you posted seemed like ones that should be covered by PR #108590, but its possible I'm misunderstanding something about them.)

If you could post a concrete self-contained example, in a form similar to that shown in #62958, then that will help me figure out 1. whether PR #108590 should be able to deal with your situation, and 2. if it cannot, then what extensions of PR #108590 would be necessary to deal with your situation.

[nolanderc]

@pnkfelix There already is a self-contained example (see the playground link in the first post). I have reduced it further here:

fn main() {
    let foo = async { 123 };
    let foo_size = std::mem::size_of_val(&foo);

    let bar0 = async move { foo.await };
    let bar0_size = std::mem::size_of_val(&bar0);

    let bar1 = async move { bar0.await };
    let bar1_size = std::mem::size_of_val(&bar1);

    let bar2 = async move { bar1.await };
    let bar2_size = std::mem::size_of_val(&bar2);

    let bar3 = async move { bar2.await };
    let bar3_size = std::mem::size_of_val(&bar3);

    dbg!(foo_size, bar0_size, bar1_size, bar2_size, bar3_size);

    // These are the sizes I would expect assuming 1-byte state tag:
    assert_eq!(foo_size,  1); // ok
    assert_eq!(bar0_size, 2); // fails with `3 != 2`
    assert_eq!(bar1_size, 3); // fails with `7 != 3`
    assert_eq!(bar2_size, 4); // fails with `15 != 4`
    assert_eq!(bar3_size, 5); // fails with `31 != 5`
}

However, if async-blocks were implemented using something like enums with niche optimization, I would rather expect all cases to occupy a single byte.

[pnkfelix]

Ah, my apologies for overlooking the playground link you had provided.