-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add method for getting memory consumption of BigInt #98
Comments
I explicitly do not want to expose this. It would mean we could never make internal changes like optimizing the digit size for different architectures. Or at least we would have to abstract
We have Note that |
Yes that's correct. Ultimately we want to know how many bytes of memory are being used by the object. We discussed using
Good point, because |
It would be nice to find some common trait for this, and implement this trait for the bigint type. Example of something that might be of use: https://doc.servo.org/malloc_size_of/trait.MallocSizeOf.html Example: trait DynamicSizeOf {
fn sizeof(&self) -> usize
}
impl DynamicSizeOf for BigInt {
fn sizeof(&self) -> usize {
// arbitrarily deep query on sub structures memory usage.
}
} |
#171 makes sure that memory use is never much larger than required. I think that could be important, especially since sometimes memory gets reused from inputs to outputs for various operations. |
It would be nice to have a method for getting the memory consumption of
BigInt
s andBigUInt
s. In particular this crate is being used by RustPython, and the python spec requires builtins to implement a__sizeof__
method that returns the amount of memory used by an object in bytes. This is quite easy to calculate usingstd::mem::size_of_val
, unfortunately it requires a reference to the underlyingdata
Vec, which of course is not exposed by theBigInt
api.My proposal is to either:
data
orBigInt
/BigUInt
I would prefer the first option because it will support a lot more unforseen use cases.
See the discussion at RustPython/RustPython#1172
The text was updated successfully, but these errors were encountered: