ByteSlice::trim on ASCII whitespace is substantially slower than core::str::trim about bstr HOT 3 OPEN

I took a quick stab at improving it by replacing https://github.com/BurntSushi/bstr/blob/master/src/unicode/whitespace.rs#L7 with this:

pub fn whitespace_len_fwd(slice: &[u8]) -> usize {
    let mut i = 0;
    while i < slice.len() && slice[i].is_ascii_whitespace() {
        i += 1;
    }
    if i == slice.len() || slice[i].is_ascii() {
        i
    } else {
        WHITESPACE_ANCHORED_FWD.find_at(slice, i).unwrap_or(i)
    }
}

Which helped the improve the benchmarks above by about 30%, although it hurt the existing benchmark by around 10%.

I couldn't quite avoid off by one errors in the _rev version (and I'm not 100% certain I've avoided them in the _fwd, tbh — there are probably bugs in the transition between ascii and unicode there). I'm not really sure this is an ideal approach anyway, so I figured I'd just report the issue rather than spend more time debugging it.

from bstr.

@thomcc Thanks for diving into this! I don't quite have the bandwidth to dive into this right now. I will at least do it whenever I get back around to releasing 1.0 in order to minimize context switching. If you do want to submit a PR with your current work, then I think that sounds good to me given the 10% loss but 30% gain. But more broadly, I certainly agree that optimizing for the ASCII case makes sense. I'd be happy to do that even if it makes the fully general Unicode case a good deal worse.

from bstr.

Just to re-iterate my previous comment: I'm generally okay with giving up a small loss for non-ASCII in favor of making the ASCII case much faster.

I'm not going to get to this for 1.0 though, which is okay, since this is an internal detail.

from bstr.