‘More optimal' is oxymoronic; ‘better’ is just that.
I prefer "more betterer".
Choosing a more optimal `String` type
11–20 of 24 posts
Re: Choosing a more optimal `String` type
#12There should be a from_raw_parts-like interface for Arc that can construct one out of a pointer to a T + control block. That way you can shift the string data over and stick the control block inline (which is how I assume it's laid out in memory) and convert String to Arc for free (well not free, shifting takes O(n), but so does the copying in Arc::new, so in the end you do end up avoiding an allocation for free)
Re: Choosing a more optimal `String` type
#13Aaah, `Cow`, the unloved child ...
I love Cow, except when it goes mut.
Re: Choosing a more optimal `String` type
#14Re: Choosing a more optimal `String` type
#15Re: Choosing a more optimal `String` type
#16There should be a from_raw_parts-like interface for Arc that can construct one out of a pointer to a T + control block. That way you can shift the string data over and stick the control block inline (which is how I assume it's laid out in memory) and convert String to Arc for free (well not free, shifting takes O(n), but so does the copying in Arc::new, so in the end you do end up avoiding an allocation for free)
Unfortunately, this can't really be done efficiently with how allocation works in Rust. A String is always allocated with alignment 1, but an Arc's control block requires usize alignment. An allocated pointer can't be deallocated with a different alignment than it was allocated with, nor can its alignment be changed when it is reallocated. Thus, the from_raw_parts() idea would be unusable for any types with less than usize alignment.
(And the control block really does need to be aligned, since otherwise we couldn't perform atomic operations on it.)
Re: Choosing a more optimal `String` type
#17Earlier quoted context omitted.
From 1983: Although "optimum" is an absolute term, like "unique", it became common verbal practice to make it relative: "not quite optimum" or "less optimum" or "not very optimum". Mel called the maximum time-delay locations the "most pessimum". https://users.cs.utah.edu/~elb/folklore/mel-annotated/node1....
Even worse! ‘Optimum’ in English is a noun, not an adjective.
From 1993:
Verbing weirds language.
Re: Choosing a more optimal `String` type
#18There should be a from_raw_parts-like interface for Arc that can construct one out of a pointer to a T + control block. That way you can shift the string data over and stick the control block inline (which is how I assume it's laid out in memory) and convert String to Arc for free (well not free, shifting takes O(n), but so does the copying in Arc::new, so in the end you do end up avoiding an allocation for free)
Unfortunately, this can't really be done efficiently with how allocation works in Rust. A String is always allocated with alignment 1, but an Arc's control block requires usize alignment. An allocated pointer can't be deallocated with a different alignment than it was allocated with, nor can its alignment be changed when it is reallocated. Thus, the from_raw_parts() idea would be unusable for any types with less than…
> A String is always allocated with alignment 1, but an Arc's control block requires usize alignment.
I'll add this to my list of reasons why alignment is terrible.
Re: Choosing a more optimal `String` type
#19Optimal is optimal. There is such thing as “more optimal”. It’s either optimal or it isn’t.
Re: Choosing a more optimal `String` type
#20Optimal is optimal. There is such thing as “more optimal”. It’s either optimal or it isn’t.
Something that is optimal under some set of assumptions and under some specific conditions is likely not optimal under all conditions. Does that mean it's not optimal under any conditions? If not, is something that is optimal under more conditions not "more optimal"?