IArray: avoid heap allocation if there is only one element #38
Conversation
|
One item is obvious good optimization, but what if there is an optimal number other than 1 that could be used? |
It's best to use Rc in that case. The optimization is so that you can clone the IArray by cloning it's single item directly if there is only one. If there are more items, then every items need to be cloned. So I think in that case it's best to use Rc. |
| @@ -216,7 +216,8 @@ impl<T: ImplicitClone + 'static> IArray<T> { | |||
| pub fn get_mut(&mut self) -> Option<&mut [T]> { | |||
| match self { | |||
| Self::Rc(ref mut rc) => Rc::get_mut(rc), | |||
| Self::Static(_) | Self::Single(_) => None, | |||
| Self::Static(_) => None, | |||
| Self::Single(ref mut a) => Some(a), | |||
There was a problem hiding this comment.
change is not reflected in the doc above?
There was a problem hiding this comment.
I think its different semantics from Rc::get_mut, since every clone of single item arrays will now be mutable and different from original, so iarray != iarray.clone()...some mutation via get_mut()... (Rc prevents mutation via get_mut() if there is a clone), but I guess its fine to do that?
There was a problem hiding this comment.
Leaving this discussion as unresolved as I think it's interesting for the future
There was a problem hiding this comment.
I guess its fine to do that?
no idea xD tbh I wasn't too much in favor of adding mutable API. I was a bit in a doubt about that
|
@kirillsemyonkin do you think I should revert eb484ec? |
|
Actually... xD #15 I was all in favor for it |
Working on Yew at the moment and I would like to refactor NodeSeq to use
IArray. It already works as is but I thought it would be nice if we could avoid
unnecessary allocations, particularly when there is only one item in the array.