2 ms·
Mistakes are always easy to recognize in retrospect, so hopefully this comment isnt too unfair, but one thing that caught me about this, is that logically it ma
by bawolff 4mo ago
Mistakes are always easy to recognize in retrospect, so hopefully this comment isnt too unfair, but one thing that caught me about this, is that logically it makes no sense. You would never use a bloom filter for just 10 entries. If you have only 10 entries it is almost certainly faster to skip the bloom filter. So i feel like that is the part that should have instantly stood out.
[Obviously, i've made my own silly mistakes over the years, many much sillier than this, its just weird to describe this one as only detectable by profiling]
- FarmerPotato 4mo agoSure, it logically makes no sense. But while learning a new subject, have you never made a silly mistake like: bool getSchemaSizes(size_t * expectedBatchSize, size_t * expectedEntriesPerBlock) { ... } size_t expectedEntriesPerBlock, expectedBatchSize; getSchemaSizes(&expectedEntriesPerBlock, &expectedBatchSize) initBloomFilter(expectedEntriesPerBlock)
- bawolff 4mo agoI said as much in my comment.
- HelloNurse 4mo agoThe quoted code suggests that the wrong sizes aren't evident constants in code (there is a function to compute/retrieve them) and extra inspection during debugging is the most plausible way to detect them. Hopefully this kind of bug is enough to teach the important of measuring, logging and testing to a naive optimist.