Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

aasheesh.vercel.app

Post reply on HN
Print view View original

21–30 of 33 posts

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

#21

Post by Retr0id »

FarmerPotato wrote: post #12
Retr0id wrote: 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…

I make all sorts of silly mistakes, but I'd rarely say that running the code is the only way to detect issues.

I also don't think the author wrote much of their codebase, or much of their blog post, but that's the brave new world we're living in.

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

#22

Post by jasonwatkinspdx »

ignoreusernames wrote: post #16
Retr0id wrote: 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.

Yeah, especially a bloomfilter which has a pretty easy formula for its false positive rate.

A lot of people know the basic rule of thumb that a byte per element gives you a bit more than a 1% false positive rate.

But even just thinking about it for half a second from a balls and bins perspective, 100k items into 100 binary bins is obviously gonna saturate.

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

#23

Post by sheepcow »

> A few weeks ago I wanted to understand how the storage engine inside RocksDB actually works. Not read about it. Build it.

Immediate tell that this was written by AI. Another thing I've noticed lately - AI's overuse of "every":

> Every batch of writes called `file.Write` on the write-ahead log.

> Every read was scanning entire SSTable files.

> Every bit is set.

> Every value matches.

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

#24

Post by FarmerPotato »

shermantanktop wrote: post #17
FarmerPotato wrote: post #12

Earlier quoted context omitted.

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…

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.

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

#25

Post by jmalicki »

Retr0id wrote: post #15
jmalicki wrote: post #2

Writing to disk for every write is required, otherwise you're not durable. Sure it's faster to never write to disk, then you reboot and you've lost data. /dev/null is a webscale database that is even faster!

There are a lot of use cases where you only truly need consistency, and durability can take a back seat. RocksDB for example does not fsync its WAL writes in the default configuration. https://github.com/facebook/rocksdb/wiki/WAL-Performance#non...

If you can't at least guarantee write ordering you don't even have consistency.

Fsync is often used when the data doesn't truly need to be on disk, because there aren't very good write ordering APIs exposed, even if that's all you truly need.

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

#26

Post by FarmerPotato »

sheepcow wrote: post #23

> A few weeks ago I wanted to understand how the storage engine inside RocksDB actually works. Not read about it. Build it. Immediate tell that this was written by AI. Another thing I've noticed lately - AI's overuse of "every": > Every batch of writes called `file.Write` on the write-ahead log. > Every read was scanning entire SSTable files. > Every bit is set. > Every value matches.

Well, this is sad.

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

#27

Post by tensegrist »

Retr0id wrote: 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.

i don't know why you're trying to analyze the meaningfulness of sentences that are not the results of a human thought process but are clearly rhetorical flourishes from an llm that "feels" compelled to fill its prose with them

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

#28

Post by Retr0id »

tensegrist wrote: post #27
Retr0id wrote: 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.

i don't know why you're trying to analyze the meaningfulness of sentences that are not the results of a human thought process but are clearly rhetorical flourishes from an llm that "feels" compelled to fill its prose with them

Comments that explicitly call out an article as slop tend to get downvoted (or disagreed with), it's best to guide the reader towards their own conclusions.

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

#29

Post by paulb73 »

Retr0id wrote: 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.

Isn't this what units tests are for?

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

#30

Post by kristianp »

sheepcow wrote: post #23

> A few weeks ago I wanted to understand how the storage engine inside RocksDB actually works. Not read about it. Build it. Immediate tell that this was written by AI. Another thing I've noticed lately - AI's overuse of "every": > Every batch of writes called `file.Write` on the write-ahead log. > Every read was scanning entire SSTable files. > Every bit is set. > Every value matches.

Also the header "The honest benchmarks" is an irritating LLM style. And all the commas! So many commas and short sentences! E.g: "Same database, same machine. The only difference is the write pattern.". It's so bad I thought someone might be copying LLM style, because the writing seems so stilted.
Post reply on HN