-
Notifications
You must be signed in to change notification settings - Fork 432
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 performance documentation for WeightedIndex #594
Conversation
Fixes the WeightedIndex-specific parts of #116 |
I had to revert the changes to This is probably fixable somehow, but since this changed was tangential to this PR anyway, I'll leave it for a separate PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
What was the missing changes?
src/distributions/weighted.rs
Outdated
/// type of those weights. However, since `Vec` doesn't guarantee a particular | ||
/// growth strategy, additional memory might be allocated but not used. | ||
/// The `WeightedIndex` object also contains a [`Uniform<X>`] object, though | ||
/// for primitive types, this doesn't allocate any memory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure which part you're saying is is incorrect. Uniform<X>
certainly has size, but it doesn't allocate memory (from the heap).
I'm also not counting the "inline" part of Vec<X>
as allocation, which is why those bytes are not mentioned. Nor things like alingment bytes.
Generally the easiest way to account for the "inline" parts of objects is to use mem::size_of<WeightedIndex<X>>()
. That'll account for all those bits, but won't account for memory allocations, which is why I focused more on talking about memory allocations.
Do you have any suggestions for wording to make that more clear?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True; I skim read. However #116 asks for documentation on memory usage, not allocations, and as far as I'm aware this is what is usually more interesting (though one can separate heap and stack usage).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess both are useful in different situations. I pushed an updated version, let me know if it matches what you had in mind.
Not sure what you mean here? |
You mentioned you had to revert some changes but those aren't in the commit, so I wondered what they are? |
Ah. I wanted to add the "See the [module documentation] on how to implement [Uniform] range sampling for a custom type." text, which we currently have on the traits, also to the documentation of the |
Also includes a small documentation improvement for
Uniform