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
This crate currently implements a trait-based measurement approach, where trait impls return the amount of memory that their types requested be allocated.
malloc_size_of is an internal component of Servo (that they built to replace their heapsize crate). The primary difference is that the trait takes an allocator argument, so that the allocator can be queried directly for the size of the allocated memory. This prevents under-counting for small or unaligned allocations (in that the allocator might allocate more memory than is requested). However, for some types it requires an API that not all allocators support, and in the absence of that API, it uses the same calculation approach as heapsize and memuse.
We should look over malloc_size_of for useful ideas. In particular, I'd like to make it possible for callers to get "real allocation" results if they have access to an allocator of the correct type, but not require it (as I think the calculation approach can be made accurate enough that for large types the simpler API suffices).
The text was updated successfully, but these errors were encountered:
This crate currently implements a trait-based measurement approach, where trait impls return the amount of memory that their types requested be allocated.
malloc_size_of
is an internal component of Servo (that they built to replace theirheapsize
crate). The primary difference is that the trait takes an allocator argument, so that the allocator can be queried directly for the size of the allocated memory. This prevents under-counting for small or unaligned allocations (in that the allocator might allocate more memory than is requested). However, for some types it requires an API that not all allocators support, and in the absence of that API, it uses the same calculation approach asheapsize
andmemuse
.We should look over
malloc_size_of
for useful ideas. In particular, I'd like to make it possible for callers to get "real allocation" results if they have access to an allocator of the correct type, but not require it (as I think the calculation approach can be made accurate enough that for large types the simpler API suffices).The text was updated successfully, but these errors were encountered: