reduce binary size of levenshtein #60
Conversation
|
|
||
| for (i, a_elem) in a.into_iter().enumerate() { | ||
| result = i + 1; | ||
| let mut distance_b = i; | ||
|
|
||
| for (j, b_elem) in b.into_iter().enumerate() { | ||
| let cost = if a_elem == b_elem { 0usize } else { 1usize }; | ||
| let cost = usize::from(a_elem != b_elem); |
There was a problem hiding this comment.
I'm surprised that this change makes a difference. Just for my own learning, do you have an explanation for it?
There was a problem hiding this comment.
In theory this can make a difference because it is a branchless version. This can't lead to CPU misprediction + in this case wouldn't require the branching in the binary. E.g. when implementing a SIMD version of algorithms this would be required, since there is no branching for SIMD.
In praxis this doesn't make a difference, since this is optimized by the compiler already anyways. So this line is simply a cleanup recommended by cargo clippy.
There was a problem hiding this comment.
So the binary size difference is only because we do no longer have to special case empty strings.
This removes the special handling for an empty first string, which leads to an extra memory allocation in this case. However this reduces the binary size noticeably: opt-level=3: 961B strsim strsim::levenshtein 1.1KiB strsim strsim::levenshtein opt-level=3 888B strsim strsim::levenshtein 949B strsim strsim::levenshtein
maxbachmann
force-pushed
the
levenshtein
branch
from
35b41c7 to
5628adb
Compare
This removes the special handling for an empty first string, which leads to an extra memory allocation in this case. However this reduces the binary size noticeably:
opt-level=3:
961B strsim strsim::levenshtein
1.1KiB strsim strsim::levenshtein
opt-level=3
888B strsim strsim::levenshtein
949B strsim strsim::levenshtein