My LSM tree was slower than a B-tree. Then I profiled it

Re:My LSM tree was slower than a B-tree. Then I profiled it by bawolff on Thursday June 18, 2026 @03:59PM (#48590699)

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]

[ Parent | on HN ]

Re:My LSM tree was slower than a B-tree. Then I profiled it by FarmerPotato on Thursday June 18, 2026 @04:07PM (#48590816)

Sure, 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)

[ Parent | on HN ]

Re:My LSM tree was slower than a B-tree. Then I profiled it by bawolff on Thursday June 18, 2026 @04:10PM (#48590847)

I said as much in my comment.

[ Parent | on HN ]

Re:My LSM tree was slower than a B-tree. Then I profiled it by HelloNurse on Friday June 19, 2026 @11:34AM (#48599782)

The 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.

[ Parent | on HN ]