ScyllaDB Async Rust Driver VS latte

I want to replicate this line in `Command` (from https://github.com/scylladb/scylla-rust-driver/pull/489/files):

Client-side driver for ScyllaDB written in pure Rust with a fully async API using Tokio. Takes advantage of ScyllaDB's shard-per-core architecture for low-latency distributed apps.

Our Rust driver started as a humble hackathon project, but it has eventually grown to become our fastest and safest Cassandra Query Language (CQL) driver. We happily observed in our benchmarks that our ScyllaDB Rust Driver beats even the reference C++ driver in terms of raw performance, and that gave us an idea — why not unify all drivers to use Rust underneath?

A few weeks ago, an interesting issue appeared on our GitHub tracker. It was reported that, despite our care in designing the driver to be efficient, it proved to be unpleasantly slower than one of the competing drivers, cassandra-cpp, which is a Rust wrapper of a C++ CQL driver. The author of latte, a latency tester for Cassandra (and Scylla), pointed out that switching the back-end from cassandra-cpp to scylla-rust-driver resulted in an unacceptable performance regression. Time to investigate!

https://github.com/scylladb/scylla-rust-driver perhaps? No sure about licensing though

This tool is probably the fastest in its class - does this code look like having a lot of lifetimes or other cryptic syntax?

- https://github.com/pkolaczk/latte/blob/main/src/main.rs

- https://github.com/pkolaczk/latte/blob/main/src/exec.rs

There was one fundamental "aha" moment for me when it clicked: move semantics.

> Does https://github.com/pkolaczk/latte count?

This is just Rust code. Where is the equivalent Java code?

> Or the Optional cost described on my blog here: https://pkolaczk.github.io/overhead-of-optional/?

Why aren't you using OptionalLong[1]? You shouldn't use Optional, that's never a good choice. At any rate, nobody should be claiming Java optionals are are free, they're a high level abstraction and absolutely do not belong in hot codepaths.

In general it's fairly easy to construct benchmarks that favor any particular language, which is why you constantly see these blog posts about how high level interpreted languages (JS, Haskell) are faster than C++.

> And what do I do with that knowledge if it turns out the optimization didn't happen?

The way the JIT works is by aggressively overassuming, and then recompiling with more generalized interpretations of the code when assumptions turn out to be false. But the wider problems of compilers occasionally generating suboptimal instructions isn't something that is Java specific.

[1] https://docs.oracle.com/en/java/javase/12/docs/api/java.base...

A few weeks ago, an interesting issue appeared on our GitHub tracker. It was reported that, despite our care in designing the driver to be efficient, it proved to be unpleasantly slower than one of the competing drivers, cassandra-cpp, which is a Rust wrapper of a C++ CQL driver. The author of latte, a latency tester for Cassandra (and Scylla), pointed out that switching the back-end from cassandra-cpp to scylla-rust-driver resulted in an unacceptable performance regression. Time to investigate!