Description:
The Read counter in bf-tree's internal metrics is only incremented within the BfTree::read() method. However, the PageCacheWrapper in the benchmark/ subdirectory implements its point-read logic using db.scan_with_count(key, 1, ...).
Because this approach bypasses the BfTree::read() method, point-read operations are not tracked in the Read counter, leading to a reported value of "Read": 0 in benchmark JSON results, even when throughput is high.
Proposed Fix:
Manually invoke the counter!(Read) macro within the read() implementation of the PageCacheWrapper to ensure these operations are consistently tracked alongside other engines.
Example Fix:
// benchmark/src/wrappers/page_cache_wrapper.rs
fn read(&self, key: &[u8], value: &mut [u8]) -> usize {
bf_tree::counter!(Read); // Ensure point-reads via scan are recorded
let mut iter = self.db.scan_with_count(key, 1, ScanReturnField::Value)
.expect("Failed to create scan iterator");
// ...
}
Description:
The
Readcounter inbf-tree's internal metrics is only incremented within theBfTree::read()method. However, the PageCacheWrapper in thebenchmark/subdirectory implements its point-read logic usingdb.scan_with_count(key, 1, ...).Because this approach bypasses the
BfTree::read()method, point-read operations are not tracked in theReadcounter, leading to a reported value of"Read": 0in benchmark JSON results, even when throughput is high.Proposed Fix:
Manually invoke the
counter!(Read)macro within the read() implementation of the PageCacheWrapper to ensure these operations are consistently tracked alongside other engines.Example Fix: