For easy to miss context: This seems to be mainly about measuring the change of stack efficiency of rust compared to a C++ base line. Given who the author is

For easy to miss context: This seems to be mainly about measuring the change of stack efficiency of rust compared to a C++ base line. Given who the author is I'm pretty sure they know that e.g. having more stack movement can be better then having more heap allocations. But there is a list of ways you can reduce stack memory movement as compiler optimizations without allocating heap memory, and AFIK rust doesn't yet fully take advantage of many of them. Additionally sometimes trading a lot of stack movements with a single allocation can be quite a bit faster, e.g. why anyhow does a thin-pointer + inlined vtable optimization. So I think the side is mainly for tracking improvements in compiler code generation and secondary if rustc uses some thin-pointer optimizations in places where it does yield some benefits.