[Ne02ptzero]

> Executing cargo bench on Limbo’s main directory, we can compare SQLite running SELECT * FROM users LIMIT 1 (620ns on my Macbook Air M2), with Limbo executing the same query (506ns), which is 20% faster.

Faster on a single query, returning a single result, on a single computer. That's not how database performance should be measured or compared.

In any case, the programming language should have little to no impact on the database performance, since the majority of the time is spent waiting on io anyway

[glommer]

The goal here is not to claim that it is faster, though (it isn't, in a lot of other things it is slower and if you run cargo bench you will see)

It is to highlight that we already reached a good level of performance this early in the project.

Your claim about the programming language having no impact is just false, though. It's exactly what people said back in 2015 when we released Scylla. It was already false then, it is even more false now.

The main reason is that storage is so incredibly fast today, the CPU architecture (of which the language is a part) does make a lot of difference.

[vessenes]

Yo glommer, I am ... very surprised to see any benchmark beat the micro-tuned sqlite so early, congrats. Where do you think rust is picking up the extra 100ns or so from a full table scan?

[pkolaczk]

> It is to highlight that we already reached a good level of performance this early in the project.

This is the right thing to do. It's a pity so many projects don't keep an eye on performance from the very first day. Getting high performing product is a process, not a single task you apply at the end. Especially in a performance critical system like a database, if you don't pay attention to performance and instead you delay optimizing till the end, at the end of the day you'll need to do a major rewrite.

[glommer]

thanks. I am sad, but not that surprised, that a lot of people here are interpreting this as we claiming that we're already faster than sqlite all over.

I don't even care about being faster than sqlite, just not being slower, this early, is already the win I'm looking for.

[AlotOfReading]

Not sure which other comments you're seeing, but my original comment wasn't intended that way.

[pkolaczk]

> In any case, the programming language should have little to no impact on the database performance, since the majority of the time is spent waiting on io anyway

That was true maybe 30 years ago with spinning disks and 100 mbit ethernet. Currently, with storage easily approaching speeds of 10 GB/s and networks at 25+ Gbit/s it is quite hard to saturate local I/O in a database system. Like, you need not just a fast language (C, C++, Rust) but also be very smart about how you write code.

[hinkley]

I can’t trust benchmarks on code that isn’t feature complete. The missing functionality is never free.

[avinassh]

> In any case, the programming language should have little to no impact on the database performance, since the majority of the time is spent waiting on io anyway

may be! However, Rust makes some things easier. It is also easy to maintain and reiterate