Terrible perfomance of the iterator str::bytes().zip(str::bytes())

[IBUzPE9]

I compared the performance of three equivalent functions:

pub fn chars_zip(x:&str, y:&str) -> usize {
  x.chars()
    .zip(y.chars())
    .filter(|&(xc, yc)| xc != yc)
    .count()
}

pub fn bytes_zip(x:&str, y:&str) -> usize {
  x.bytes()
    .zip(y.bytes())
    .filter(|&(xc, yc)| xc != yc)
    .count()
}

pub fn slice_zip(x:&str, y:&str) -> usize {
    let x = x.as_bytes();
    let y = y.as_bytes();
    x.iter()
        .zip(y)
        .filter(|&(xc, yc)| xc != yc)
        .count()
}

This is results (release mode):

chars_zip       0.1450s
bytes_zip       0.2599s
slice_zip       0.0643s

Playground

[sfackler]

IIRC zip is specialized for slices which is why the last case is so much faster.

[leonardo-m]

Try also to compile with -C opt-level=3 -C target-cpu=native

[leonardo-m]

A question could be: is it possible for bytes() to return something similar to as_bytes().iter() ?

[IBUzPE9]

@leonardo-m

Try also to compile with -C opt-level=3 -C target-cpu=native

It makes the slice_zip() two times faster, the speed of the bytes_zip() and the chars_zip() has stayed the same as before.

[bluss]

You've discovered the "untweaked speed" of zip ☹️, which is what str::bytes has.

str::bytes can implement TrustedRandomAccess the same way slice iterators do, in fact str::bytes is just a newtype around an iterator that already implements that trait.