I am developing a fairly standard buffered binary scanner for a custom format.

During development, I experimented with different approaches to optimize for throughput while skipping chunks.

I found one particular implementation was beating the others by a large margin.

So I polished it a bit. But then the performance regressed when I removed a code path that was not even being executed in the tests.

I was able to pin it down to a line that was allocating a Vec through the vec![] macro.

This line originally was in fn skip() which is called from fn next(). But I found moving it anywhere within the Scanner impl was enough to keep the throughput gain, to the point it does nothing and now sits at the constructor and is probably optimized away.

impl<R: BufRead> Scanner<R> {
    pub fn new(reader: R) -> Self {
        // Remove this line and throughput tanks! 
        let _ = vec![0;0];

        Scanner {
            reader,
            buffer: vec![0; BUFSIZE],
            bufpos: 0,
            buflen: 0,
            header: None,
            hasval: false,
        }
    }

Despite it clearly doing nothing, by removing it we go from…

jon@jonmbpp fcodec λ cargo run --release --bin bench_bin_scan /tmp/fifo.fifob
    Finished `release` profile [optimized] target(s) in 0.00s
     Running `target/release/bench_bin_scan /tmp/fifo.fifob`
file: /tmp/fifo.fifob
bytes: 429496729
rows: 26843546
rows/s: 354419760.06
time: 0.076s
throughput: 5.28 GiB/s (5.67 GB/s)

to…

jon@jonmbpp fcodec λ cargo run --release --bin bench_bin_scan /tmp/fifo.fifob
    Finished `release` profile [optimized] target(s) in 0.00s
     Running `target/release/bench_bin_scan /tmp/fifo.fifob`
file: /tmp/fifo.fifob
bytes: 429496729
rows: 26843546
rows/s: 225853748.59
time: 0.119s
throughput: 3.37 GiB/s (3.61 GB/s)

I know how sensitive high-performance code is, and that there's a myriad of things that could impact the bottom line, but this is illogical to me.

7 posts - 5 participants

Read full topic