I'm not sure I'm sold on this one. Interesting food for thought but I'll have to mull it over for a while I think. I'm concerned about the performance implications of querying like this.

Several ways to deal with the task, which are the performance implications? Clearly coroutines aren't the best tool for the job here.

Nice results. Interesting implementation too. I wonder if some of it will make its way to the glibc or musl.

If you still needed to be convinced you need to use std::array and std::span, here is the proof.

Good reminder that packing your data is generally the right move when squeezing for performances.

Looks like there is still some work required on QUIC. There is a path forward though.

An old article but a good reminder: you have to choose between latency and throughput, you can't have both in the same system.

Interesting reason which would explain the Selenium flakiness. It's just harder to write tests with race conditions using Playwright.

SIMD is hard to use, not all problems can apply to it. But when they can, the performance gain can be great.

Interesting, it confirms garbage collectors can be the source of unrecoverable performance degradation in request based systems.

Or why anticipating too much is merely a gamble. You can be lucky, but how often will you be? Also I agree that in such cases the performance will be impacted longer term leading to a death by thousands of paper cuts.

Compile time reflection in C++ will indeed be a big deal.

Interesting dive into some of the performance improvements introduced into recent CPython releases.

Interesting experiment showing that BLOBs in a database can be a good alternative to individual files on a filesystem in some contexts.

Interesting article about what's coming for the branch predictor in the Zen 5 architecture from AMD.

A paper listing patterns to reduce latency as much as possible. There are lesser known tricks in there.

Another interesting algorithm to handle using SIMD.

Forced to use UUID as primary key in a table? Then make sure to use them properly to not kill the performance more than necessary. Ideally use something else though.

As Moore's law fades away this question is indeed essential. Looks like there will be more pressure on software and algorithms than before (at last one might say, we had decades of waste there). Streamlining hardware architectures will have a role too, we might see simpler cores in greater numbers.

Interesting case, when everything else gets faster, memory copies might start to become the bottleneck.