Comment by xray2
1 year ago
I’ll take the faster c version anyday over the rust. How are those conditional if statements working for you all?
1 year ago
I’ll take the faster c version anyday over the rust. How are those conditional if statements working for you all?
The benchmarks in the post indicate that Limbo is more performant than SQLite, not less.
> 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
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.
4 replies →
> 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.
I can’t trust benchmarks on code that isn’t feature complete. The missing functionality is never free.
> 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
Related: https://old.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn...
C libraries aren't automatically the fastest option, there's a lot of C code which has stagnated on the performance front but is still widely used because it's battle tested and known to be robust by C standards.
There's still an element of truth in the idea that C is going to be faster by default. There's simply a much lower bar to writing fast (and unsafe) C. Fast Rust demands considerably more thoughtfulness from the programmer (at least for me).
5 replies →
This is often true on the journey to reach feature-parity with an original codebase.
The reason is obvious, of course: it has less features, and doing nothing is always faster than doing something.
Once it's feature complete, then meaningful comparisons can be made. For now, it's puffery.
be careful with that, though. In a lot of ways it is still slower.
The goal with that was just to demonstrate that there's nothing really there that is fundamentally slower, and the perf is already on par in the areas where we spent cycles on.
Microbenchmarks are not particularly predictive of performance with real workloads. And there's just one microbenchmark claimed here.
That doesn't mean much until it's got feature parity.
what on earth do you mean by 'conditional if statements' if not a tautology?