Because the parser works with byte slices (&[u8]) rather than string slices (&str), even when the user parses a string slice, we first convert to &[u8] to parse, and then do a checked conversion back, despite never splitting in between character bytes. This can be especially noticeable for URI lines, where we don't do any meaningful parsing, and just pay an unnecessary cost of converting to bytes and then checked back again to string.
Either the library should deal with &str internally (given that HLS requires the input to be UTF-8 anyway), or, we should provide more optimized methods for &str input.
Note, &[u8] was used, as it was thought that it may make it more convenient to be used with Read / BufRead; however, we have not implemented those methods yet.
Because the parser works with byte slices (
&[u8]) rather than string slices (&str), even when the user parses a string slice, we first convert to&[u8]to parse, and then do a checked conversion back, despite never splitting in between character bytes. This can be especially noticeable for URI lines, where we don't do any meaningful parsing, and just pay an unnecessary cost of converting to bytes and then checked back again to string.Either the library should deal with
&strinternally (given that HLS requires the input to be UTF-8 anyway), or, we should provide more optimized methods for&strinput.Note,
&[u8]was used, as it was thought that it may make it more convenient to be used withRead/BufRead; however, we have not implemented those methods yet.