Live data from Hacker News

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

aasheesh.vercel.app

31–33 of 33 posts

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

#31
post #7

> A 100-bit bloom filter holding 100,000 keys is saturated instantly > This is the kind of bug you only find by building the thing and measuring it. No? I mean, maybe if you're vibecoding it's the only way, but in the prehistoric days you could reason about what code would do before you ran it.

Do you think the author is somehow capable of writing the entire codebase, but not able to reason about code??? I'm sure you've never made a silly mistake where you passed the wrong integer parameter to a function, stared at your screen, and failed to notice it. Or, forgot the order of arguments to calloc(). If you're saying that profiling is for those too lazy to reason about their code, you're distorting the whole…

The author didn't write the blog post so my default assumption is they didn't write the code either.

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

#32

Earlier quoted context omitted.

I'm called in to consult on a performance problem on a scaled service. Team was load testing their code and seeing low throughput: Me: so you have an in-memory cache, right? Them: yes! Me: what is the TTL? Them: Oh, it's not set, oops. Here, let's set it to 1 minute. Hey look, the performance went way up! Me: okay, great. When you say 1 minute, do you mean 60 seconds? Them: uh...wait...uh....oh, the unit is seconds.…

So the author is doing a self-learning exercise about profiling pre-production code, and you're disagreeing with them by comparing it to a commercial contract. I'm sure you've never, ever made a dumb mistake while getting paid.

I've even made dumb mistakes while NOT getting paid. But even so, I have no idea what you're talking about.

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

#33
post #19

Earlier quoted context omitted.

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)

I said as much in my comment.

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.

Post reply on HN