You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 10, 2023. It is now read-only.
I have an enum with a variant that contains just a Vec<u8>. I derive HeapSizeOf on the enum using the macro from the heapsize_derive crate. Results are the same when I manually implement HeapSizeOf by calling heap_size_of_children on the inner values.
When I query the inner len and capacity of the vector I get 4194575. When I call heap_size_of_children on the enum, I get 5242880. Where could that extra size come from? I'm thinking allocator overhead, is heapsize able to account for that? Memory usage reported by the OS actually agrees with the smaller number, but I suppose the additional pages would not have been touched.
Maybe relevant?
I called shrink_to_fit on the vector
I'm running under WSL which should be linking jemalloc
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Noob question:
I have an enum with a variant that contains just a
Vec<u8>
. I deriveHeapSizeOf
on the enum using the macro from the heapsize_derive crate. Results are the same when I manually implementHeapSizeOf
by callingheap_size_of_children
on the inner values.When I query the inner
len
andcapacity
of the vector I get4194575
. When I callheap_size_of_children
on the enum, I get5242880
. Where could that extra size come from? I'm thinking allocator overhead, is heapsize able to account for that? Memory usage reported by the OS actually agrees with the smaller number, but I suppose the additional pages would not have been touched.Maybe relevant?
shrink_to_fit
on the vectorThe text was updated successfully, but these errors were encountered: