Benchmarks for find_entry #180
Conversation
src/index.rs
Outdated
| key_prefix: u64, | ||
| sub_index: usize, | ||
| chunk: &[u8; CHUNK_LEN], | ||
| ) -> (Entry, usize) { | ||
| assert!(chunk.len() >= CHUNK_ENTRIES * 8); |
There was a problem hiding this comment.
Is the assert still needed ?
src/index.rs
Outdated
| let i = index % 64; | ||
| let x = f(&table, keys[i], 0, &chunk).1; | ||
| assert_eq!(x, i); | ||
| index += 1; |
There was a problem hiding this comment.
Would make sense to me to have the 64 query under iter (so nb iter don't interfer (actually with this use case it probably does not really matter)).
There was a problem hiding this comment.
Under real workload chunks are never full. I'd guess average occupancy is about 33%. With just a few entries base variant will probably be faster, while with 64 entries simd will probably be faster. This cycle averages it.
src/index.rs
Outdated
| IndexTable { id: TableId(18), map: RwLock::new(None), path: Default::default() }; | ||
| let mut chunk = [0u8; 512]; | ||
| let mut keys = [0u64; 64]; | ||
| let mut rng = rand::thread_rng(); |
There was a problem hiding this comment.
Not too sure if we should bench on random content (could be just random from a fix seed).
There was a problem hiding this comment.
OK, even though It does not matter too much what the entry bits are, as long as they are different.
Also added a small optimization for
chunk_at