Idea: guestimate of size of datatype

[drXor]

As I understand it, semver relates to how the machine sees our code and reasons about compatibility.

Exposing the exact size makes the size an API commitment. Exposing “fits in a cache line” is only questionably an API commitment.

[derekdreery]

Exposing the exact size makes the size an API commitment. Exposing “fits in a cache line” is only questionably an API commitment.

It would only ever be a best estimate. It would be different on different architectures, and between different versions of the compiler. There would be no promises made about the accuracy - it’s just a hint.

What it does do is act as a hint on where to profile - if a struct is big, profiling with and without boxing is probably worth doing. If it’s smaller than a pointer, probably not.

[Yato]

You can use std::mem::size_of to find the size of a struct in bytes, but as others have noted don’t rely on this staying the same across different compilers and architectures.

[derekdreery]

You can use std::mem::size_of to find the size of a struct in bytes, but as others have noted don’t rely on this staying the same across different compilers and architectures.

This is what you would use to provide the hint.

[Yato]

If the size of a type matters, then you should probably check the size of your types anyways. How will generic types be handled, in general you can’t know the size of it before monomorphozation

[derekdreery]

How will generic types be handled, in general you can’t know the size of it before monomorphozation

I would just not give estimates for type constructors, only concrete types.

[H2CO3]

There’s already a similar lint in Clippy; I argue that if anything, this should be a Clippy lint which is maybe allow-by-default or warn-by-default. So instead of printing the size of every single data structure, there could exist a warning for extremely large structures which might need to be broken up into parts, boxed, etc.

Exposing the exact size makes the size an API commitment.

Exactly – and in addition, if something is exposed, people will rely on it, no matter how many flashing red warnings saying “THIS IS ONLY AN ESTIMATE AND ALWAYS SUBJECT TO CHANGE” there might be.

[nnethercote]

The (Nightly) compiler can already do this, via the -Zprint-type-sizes option. It’s very effective, I’ve used it myself on multiple occasions. See this blog post for details.

(That doesn’t involve rustdoc, which means the sizes don’t appear in documentation, so I’m not sure if it meets your requirements. If not, at least the machinery is already in place within the compiler, and presumably could be hooked up to rustdoc with some effort…)

[derekdreery]

I don’t really have any requirements, I was just throwing the idea up.

[kornel]

Please don’t “throw ideas up”. The language has more ideas than it can deal with, and there is very real cost of every addition, and even evaluation of ideas. If there isn’t a big real need for something, forget it.

[comex]

Please don’t “throw ideas up”. The language has more ideas than it can deal with, and there is very real cost of every addition, and even evaluation of ideas. If there isn’t a big real need for something, forget it.

I disagree. This is not an RFC or pre-RFC; it’s just a thread in the internals forum, which has plenty of capacity for ideas. It’s one thing if someone, say, spams the forum with a dozen half-baked ideas over the course of a month, but this OP hasn’t done that.

It’s not a bad idea, either… especially since it’s not proposing a core language feature or anything that would be subject to stability guarantees, just an implementation feature, and one that would be relatively easy to implement.

[kornel]

Fair enough

[ahmedcharles]

The docs currently allow trivially looking at the implementation of any type, which is the strongest statement that can be made in terms of stability. Stating the size of a type on a given architecture couldn’t possibly suggest a higher guarantee in terms of things not changing compared to viewing the source.

[vorner]

I have a slightly different concern ‒ could it be misleading? Specifically:

struct Indirect(Box<SomethingReallyHuge>)

This would show a small number, so one could go and create Vec<Indirect> with a lot of elements and be surprised how this 8-byte large structures ate all the RAM.

So maybe having a (collapsed by default) size analysis that would say 8 bytes inline, but some arbitrary amount on the heap?

[kornel]

If you start counting indirect memory usage, it gets hairy. For Vec usage there is extremely odd distribution — most are empty, some are huge. With a type like Vec<Vec<u8>> you don’t know if it typically costs nothing or takes 90% of your RAM.

[vorner]

That’s actually what I was trying to say. If I was rustdoc, I wouldn’t dare to claim this type is small. It’s stack representation is small, but that is misleading, as that’s only half of the message. The best/most accurate answer I could give would be something like:

• stack: 24B
• heap: 0-∞

But I don’t know if this is in any way useful.

[kornel]

It’s worth noting that Clippy already has a warning about surprising enum size (e.g. if you have enum (u32, [u8; 1000])).

If the goal is to warn about excessive stack usage, or maybe too much copying for return types, such things can be added to Clippy. That’d work better than checking docs manually type by type.

[ahmedcharles]

I’m not sure why the concern is potential confusion rather than the opportunity being potential education. If you can have a note that says “the size of this object on x86_64 is X bytes, click here to learn more” (or whatever the bikeshed results in), then you can have an entire page devoted to educating new Rust users on the difference between direct and indirect memory usage of objects. That seems like a win to me.

[comex]

It’s not useful if you want to figure out how much RAM you’re going to use. But it is useful for a specific purpose: figuring out whether it’s okay for your hot paths to use that type directly in function arguments or return values, or whether you should use some sort of pointer instead. That includes Box, but also simple things like having arguments of type &Foo instead of Foo, or having an ‘out pointer’ argument of type &mut Foo instead of returning Foo. Or perhaps fancier tricks using unsafe code… (and maybe someday we’ll have something like &move pointers built into the language…)

[derekdreery]

Adding to clippy would achieve the goal i think.