perf(rust, polars): use iterator instead of loop polars_io::csv::parser::skip_condition

[dannyvankooten]

This guarantees the removal of bounds checking inside the loop, which allows for a very minor performance gain.

Benchmark was run using Criterion using 1M rows.

Before (using while with indexing):

parse csv               time:   [391.85 ms 394.01 ms 396.03 ms]

After (using iter().position(...)

parse csv               time:   [387.96 ms 389.62 ms 391.05 ms]
                       change: [-1.7745% -1.1159% -0.4741%] (p = 0.00 < 0.05)

Sidenote: I re-used behavior from the old implementation but there is actually a potential OOB if the predicate does not satisfy any of the remaining bytes in the input buffer. Since input.len() is returned in those cases, the consecutive line will trigger an OOB. (This was also the case in the old implementation.) I am unsure how to fix, since a pointer has to be returned...

[ritchie46]

Nice one. Just shows how often a minor code snippet is executed. :)

Sidenote: I re-used behavior from the old implementation but there is actually a potential OOB if the predicate does not satisfy any of the remaining bytes in the input buffer. Since input.len() is returned in those cases, the consecutive line will trigger an OOB. (This was also the case in the old implementation.) I am unsure how to fix, since a pointer has to be returned...

Right.. We could return an Option. by calling input.get(read..). We already do a bounds check as we do a normal indexing [] operation, so we might as well use a better OOB path than a panic.