aeledfyr / deepsize Goto Github PK

I'd love to support DeepSize for internment::ArcIntern, but doing so properly would require an interface that allows me to store which have been visited in the Context. This would also apply to any other reference-counted types presumably.

This page needs to show how the macro is supposed to be used:

https://docs.rs/deepsize/0.1.1/deepsize/macro.known_deep_size.html

@Aeledfyr

Hello, I ran into the following surprising behavior and wonder if it's intentional.

trait MyTrait {
    fn run(&mut self);
}
#[derive(deepsize::DeepSizeOf, Default)]
struct State {
    data: Vec<String>,
}
impl State {
    fn print_deepsize(&self) {
        println!(
            "[deepsize in impl block] {:p} {}",
            self,
            self.deep_size_of()
        );
    }
}
impl MyTrait for State {
    fn run(&mut self) {
        self.data.push(String::from("foobar"));
        println!(
            "[deepsize in impl XX for YY block] {:p} {}",
            self,
            self.deep_size_of()
        );
        self.print_deepsize();
    }
}
fn main() {
    let mut state = State::default();
    state.run();
}

Running this produces the following output:

[deepsize in impl XX for YY block] 0x7fff18ea0990 8
[deepsize in impl block] 0x7fff18ea0990 126

That's surprising. I expect both calls to deep_size_of() return the same result. It seems both calls resolve to the same deep_size_of() in the DeepSize library. However, the deep_size_of_children() call in it resolves to different ones. It resolves to the derived one when deep_size_of() is called in impl State, but resolves to the following one when when deep_size_of() is called in impl MyTrait for State.

impl<T> DeepSizeOf for &mut T
where
    T: DeepSizeOf +?Sized,
{
    fn deep_size_of_children(&self, _context: &mut Context) -> usize {
        0
    }
} 

Is this intended behavior or a bug in the library?

Hi! We see that you've added DeepSizeOf implementations for std::net since the 0.2.0 release. We would love to be able to use this feature. Is there a next release on the horizon?

Hey, I've noticed that currently published deepsize_derive panics on enums, although the code on master handles them fine. Looks like it just wasn't published yet?

Thank you for cutting the new deepsize-derive release (#17), much appreciated. Could you please also cut a minor release for Deepsize which bumps its dependency on deepsize-derive from 0.1.1 to 0.1.2? That way when I use Deepsize, I will transitively pull in the newer deps.

If anyone knows how hashbrown's hashmap allocates memory, can you give me pointers? Is it like the old implementation, where it was effectively the same as a Vec<(u64, K, V)>?

Hi! I noticed that the latest deepsize_derive on master is using syn/proc-macro2-quote 1.0 (as of commit ffc79ef), but that commit hasn't been released to crates.io yet! So the current crates.io release is still pulling in old dependencies.

If possible, could you please cut a new release of deepsize_derive? That way, my project can stop compiling the old 0.x dependencies :) Of course, if that's not possible, I can always just point my project at your master branch, instead of using crates.io. But a release would be helpful!

Thanks for your time!

In some cases, it may be preferable to just write a manual impl of deepsize, without using derive. For such cases, it would be nice if derive support was optional.

Specifically, I am adding deepsize to https://github.com/rust-analyzer/text_unit, and it can work without derive

For example, an Array2<u8> indeed uses https://docs.rs/ndarray/0.15.4/src/ndarray/data_repr.rs.html#21-25 which is:

pub struct OwnedRepr<A> {
    ptr: NonNull<A>,
    len: usize,
    capacity: usize,
}

For example, it can be as big as 10MB, but can deepsize recognize it?

@Aeledfyr I am about to file a few issues, but I noticed that you are not watching this repo so you would not be notified. Consider selecting "Watching" here: https://github.com/Aeledfyr/deepsize/subscription

Moved from dtolnay/request-for-implementation#22 (comment):

Does anyone have preferences on which standard library types this is implemented for?

Hello @Aeledfyr,
I'm currently starting using this project and I find it very interesting and powerful, but sadly apparently unmaintained.

In the rust ecosystem it seems that we have a few similar libraries namely:

• get-size: which has the drawback of not properly accounting for reference-counted instances
• heapsize: which is no longer maintained and replaced by malloc_size_of which is not public and even attempting to clone the repo locally the usage experience is not very simple
• memuse: which requires manual code writing to determine heap size of objects, provides boundaries and seems to be not maintained as well
• ...

Given that in terms of easy to use this library is by far better than others (personal opinion) and that it seems to not be actively maintained I was wondering if I could do anything to support you with that.
Maybe I could help address the open PRs, support to create CI integration to have continuous testing and automated release (after tagging) such that we could maintain the library again.

Let me know what you think before investing significant time on this

There currently aren't any examples of how to implement the DeepSizeOf trait manually.

Moved from dtolnay/request-for-implementation#22 (comment):

how would I add integration for some of the dynamic storage crates (such as slotmap), without making it a dependency (only using the impl if the crate is already being used)?

Currently two methods of the DeepSizeOf trait are documented as being "internal".

I don't recognize "internal" as being standard Rust terminology. If these methods are intended to be private implementation details of the deepsize crate, implemented and called only from deepsize code, then they should not be rendered in public API documentation.

@Aeledfyr

Hi thanks for the wonderful library! I wonder how to get notified whenever the deepsize of an object changes? I need this because when the deepsize changes, I need to hint the GC of another language (indeed Dart) the latest size of this "native" data structure.

Related: fzyzcjy/flutter_rust_bridge#243

The heapsize crate is a popular crate with many crates depending on it and lots of downloads. From the description of deepsize, I can't tell what it would do differently than heapsize. It would be worth calling this out in the readme as well as rustdocs.

@Aeledfyr

Currently none of the example code or documentation shows how to use Context. I would expect to see usage examples on this page:

https://docs.rs/deepsize/0.1.1/deepsize/struct.Context.html

@Aeledfyr

Should be easy since they have no heap allocation.

A blanket impl of DeepSize for all copy types would cover a significant amount of the library comparability code in this library. Can Copy types own memory, in the sense that this library tracks?

The only type that I can think of that that conflicts with this are references; they are currently defined to not measure the referenced structure, but other structures may want special logic for that.

One way to solve it would be with specialization and a default impl of DeepSize for types with Copy, but that's still a long way off. The other would be to just make a normal impl (which would be a breaking change) and hope that no one runs into cases where a specialized implementation is needed.

In the rustdoc example it would be worth breaking down why 17 is the correct answer as a way to explain what this crate does.

@Aeledfyr