View source code
Display the source code in std/experimental/allocator/building_blocks/stats_collector.d from which this page was generated on github.
Report a bug
If you spot a problem with this page, click here to create a Bugzilla issue.
Improve this page
Quickly fork, edit online, and submit a pull request for this page. Requires a signed-in GitHub account. This works well for small changes. If you'd like to make larger changes you may want to consider using local clone.

Enum std.experimental.allocator.building_blocks.stats_collector.Options

Options for StatsCollector defined below. Each enables during compilation one specific counter, statistic, or other piece of information.

The enum base type is ulong .

Enum members

Name Description
all Combines all flags above.
bytesAll Chooses all byteXxx flags.
bytesAllocated Tracks total cumulative bytes allocated by means of allocate, expand, and reallocate (when resulting in an expansion). This number always grows and indicates allocation traffic. To compute bytes deallocated cumulatively, subtract bytesUsed from bytesAllocated.
bytesContracted Tracks the sum of all b.length - s with b.length > s in calls of the form realloc(b, s) that succeed (return true). In per-call statistics, also unambiguously counts the bytes deallocated with deallocate.
bytesExpanded Tracks the sum of all delta values in calls of the form expand(b, delta) that succeed (return true).
bytesHighTide Measures the maximum bytes allocated over the time. This is useful for dimensioning allocators.
bytesMoved Tracks the sum of all bytes moved as a result of calls to realloc that were unable to reallocate in place. A large number (relative to bytesAllocated) indicates that the application should use larger preallocations.
bytesNotMoved Tracks the sum of all bytes NOT moved as result of calls to realloc that managed to reallocate in place. A large number (relative to bytesAllocated) indicates that the application is expansion-intensive and is saving a good amount of moves. However, if this number is relatively small and bytesSlack is high, it means the application is overallocating for little benefit.
bytesSlack Measures the sum of extra bytes allocated beyond the bytes requested, i.e. the internal fragmentation. This is the current effective number of slack bytes, and it goes up and down with time.
bytesUsed Tracks bytes currently allocated by this allocator. This number goes up and down as memory is allocated and deallocated, and is zero if the allocator currently has no active allocation.
numAll Chooses all numXxx flags.
numAllocate Counts the number of calls to allocate. All calls are counted, including requests for zero bytes or failed requests.
numAllocateOK Counts the number of calls to allocate that succeeded, i.e. they returned a block as large as requested. (N.B. requests for zero bytes count as successful.)
numDeallocate Counts the number of calls to deallocate.
numDeallocateAll Counts the number of calls to deallocateAll.
numExpand Counts the number of calls to expand, regardless of arguments or result.
numExpandOK Counts the number of calls to expand that resulted in a successful expansion.
numOwns Counts the number of calls to owns.
numReallocate Counts the number of calls to reallocate, regardless of arguments or result.
numReallocateInPlace Counts the number of calls to reallocate that resulted in an in-place reallocation (no memory moved). If this number is close to the total number of reallocations, that indicates the allocator finds room at the current block's end in a large fraction of the cases, but also that internal fragmentation may be high (the size of the unit of allocation is large compared to the typical allocation size of the application).
numReallocateOK Counts the number of calls to reallocate that succeeded. (Reallocations to zero bytes count as successful.)

Authors

License

Comments