Looks like a nice kit to add to your tool belt. Does some handy checks if you have a Postgres database to manage.

No, don't go assuming you can use disks instead of ram. This is not what it is about. It shows ways to get more out of your disks though. It's not something you always need, but sometimes it can be a worth endeavor.

Clearly AMD is now well above Intel in performance around AVX-512. This is somewhat unexpected.

Some of this might sound obvious I guess. Still there are interesting lesser known nuggets proposed here.

This is unfortunately still a bit complicated for my taste. Ideally std::simd should be stabilized, but since it's not the case yet options have to be evaluated.

A long needed improvement to Java on its way to the JDK. Looking forward to this one stabilizing.

Maybe we have a path forward for performance stackful coroutine? More pieces need to fall in place but this looks promising.

Interesting to see how it behaves in practice when passing parameters by value. Turns out there are surprising patterns in the data.

This is an interesting pattern that I still seldomly meet in C++ codebases. Of course don't go overboard with it, but don't be scared of using it for wrong reasons.

Serverless based architectures leading to bad cases of complexity and latency when used for more than trivial workloads... who knew!? ;-)

This article is short but very interesting. That's indeed something to keep in mind when using Postgres, you could have surprisingly bad performance results in some cases otherwise.

First rough benchmarks for CPython 3.14. It looks like the JIT isn't giving much improvement on the cases explored, the free threading on the other hand is a clear advantage for multithreaded cases. Of course as usual Pypy is still way faster. That said, like anything else: first measure in your own context before taking any decision.

As usual, you need to measure before you jump to conclusion...

Interesting idea, trying to bridge the best of both UUID options.

Maybe it's time to stop obsessing about scale and distributed architectures? The hardware has been improved quite a bit at the right places, especially storage.

This is definitely true. Keep all this in mind when dealing with performance questions: design properly for the task, profile and profile some more, focus on the hotspots, keep things maintainable.

Of course I agree with this. We should fight undue complexity at every step. This beast tends to creep up very quickly and we're all guilty of it at times. This is indeed particularly obvious in otherwise rich languages like C++ or Rust. Those tend to push people to try to be clever and show off, often for "performance reasons". This is rarely a good idea, think twice.

I would have titled the "defer refactoring" section differently though. Probably "defer abstracting" would have fit the bill better.

A few ideas to dig deeper into for better multi threaded throughput.

Nice bag of tricks for better Rust performance at low level. The compiler is indeed helping quite a bit here.

This can be useful indeed to explore concurrency issues. It requires some work though.