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
{{ message }}
This repository has been archived by the owner on Sep 11, 2023. It is now read-only.
doing #[derive(Enum)] produces code that looks like this:
pubfnfrom_usize(v:usize) -> Scens{useScens::*;if v < 1{Zero}elseif v < 2{One}elseif v < 3{Two}elseif v < 4{Three}elseif v < 5{Four}elseif v < 6{Five}else{unreachable!()}}
This seems strange to me and the compiler: building with optimisation results in a large chain of comparisons and conditional jumps.
If instead we would generate
pubfnfrom_usize(v:usize) -> Scens{useScens::*;if v == 0{Zero}elseif v == 1{One}elseif v == 2{Two}elseif v == 3{Three}elseif v == 4{Four}elseif v == 5{Five}else{unreachable!()}}
both of these produce simpler and faster code: check if the value is in range (< 6 in this case) and then accept an answer as-is.
However I assume the if v < x + 1 implementation wasn't pick at random: is there some information about this? Is there a downside of the proposed methods? It seems very simple to switch the code over to equality check which compiler is much happier about.
These generated methods are quite hot in our code-base which is how I stumbled upon this.
w.r.t. why it was this way: I'm looking at handle_named_variant and that looks very similar except in that case we have fields which means < comparison catches it: perhaps unit was modeled on it and never adapted to do something more efficient. Maybe a range match is better there or something but that's for another day – unit variant is what I care about in this ticket.
handle_named_variant uses < because it needs to (the number of variants is variable for named variants), and I assume handle_unit_variant got < from it.
As for why if is used rather than match, this is because match arms don't accept const expressions (inline-const is currently nightly only - rust-lang/rust#76001). At some point I think I would like to implement a special case for enums that only have unit variants that uses match for those (to shorten compilation times when having a lot of enums), but I didn't do that yet
If we have an enum like this:
doing
#[derive(Enum)]
produces code that looks like this:This seems strange to me and the compiler: building with optimisation results in a large chain of comparisons and conditional jumps.
If instead we would generate
or the less-verbose
both of these produce simpler and faster code: check if the value is in range (
< 6 in this case
) and then accept an answer as-is.However I assume the
if v < x + 1
implementation wasn't pick at random: is there some information about this? Is there a downside of the proposed methods? It seems very simple to switch the code over to equality check which compiler is much happier about.These generated methods are quite hot in our code-base which is how I stumbled upon this.
Godbolt link: https://rust.godbolt.org/z/a7E3oE81s
The text was updated successfully, but these errors were encountered: