Hacker News Reader

Comment by koverstreet | Hacker News Reader

No, you don't. That'll add expensive memory reallocations; it may let you avoid the split operation but then that isn't worth it because you've added a nasty performance cliff to your insert case - you'll either be doing the memory allocation repeatedly, or you'll waste a ton of memory when your buffer is bigger than your on disk node size.

View on HN

For my workload it's optimal to keep working nodes deserialized anyway. YMMV but what I'm doing gets me over a million operations per second -- 1 Gbps of requests -- on a single CPU so I don't think I'm going far wrong.

EDIT: I just noticed you're the bcachefs author. I'm guessing you're dealing with much larger key/value pairs than I am (40+40)?

No, that's a typical size for bcachefs as well.

But I've had to optimize for memory usage, performance when working set does not fit into ram - we also don't have a serialize/deserialize step, that will really hurt you when working set doesn't fit in ram.

You want to validate when you're reading in a btree node, but you want to keep that as cheap as possible.

For avoiding the serialize/deserialize, the thing to use now would be Cap'n Proto.

Ah, that would explain it. Yeah, I have a total datastore size which is out of core, but the working set is generally in core... partly because I can use all the RAM on the system if I want to, whereas filesystems are (usually!) expected to occupy just a portion of the system memory.

FWIW, my "deserialize" doesn't involve copying all the data -- I just construct pointers into the (serialized) page. Serializing has to copy data though.

Just wanted to say, I really enjoyed reading your guys conversation, since I barely never do low-level optimizations like that. Very interesting, thanks for sharing your thoughts!

Well, bcachefs is currently the slowest of all Linux filesystems.

See https://www.phoronix.com/review/bcachefs-linux-67.

Probably more interesting to consider the follow-up article[1] after some debug code was disabled and such.

[1]: https://www.phoronix.com/review/bcachefs-benchmarks-linux67

Still dead last on a number of benchmarks, including FIO random reads, Dbench, and Postgres. And by a lot.

If I created the slowest mainstream Linux filesystem I'd be quite proud. Sneer all you want.

> No, you don't.

This is correct. Most disk-oriented DBMSs use fixed-size pages. So you can't go larger than the node size (not entirely true if using auxiliary data structures to buffer changes like an inefficient -epsilon tree).

Reply on news.ycombinator.com