Nice exploration of the GitLab database schema. This highlights and finds quite a few of the choices made with an eye on performances.

Very interesting approach to JSON parsing. Comes with a very thorough performance analysis.

Not necessarily a practical advice in most of our daily code. Still this exhibits interesting low level details about argument passing. Might come in handy in a few cases, to be kept in mind.

A very precise and thorough article about GPU occupancy. What it is, how it relates to perceived performances, it's potentisl relationship with cache thrashing and the tools you can use to measure it on AMD GPUs.

Very nice collection of stories from the trenches of Firefox development. Lots of lessons learned to unpack about optimizing for the right thing, tooling, telemetry and so on.

This is unsurprisingly highly depend on the actual code, not only on the hardware.

Seen this a bit too often indeed. When people learn about std::move they tend to sprinkle it too much preventing proper optimizations. Its use should be fairly limited usually.

Good reminder that false sharing is a real thing. It's easier to encounter than you think when you start to dabble into multi-threading.

This is indeed a nice improvement. I hope they keep working in this direction.

Interesting exploration of the performance for web resources when they're bundled or not. Also dabbles in the reasons behind the exhibited performances, definitely to keep in mind.

Looks like an interesting serialization framework. If it holds true to its claims it could be very useful in some place.

Will AMD really turn this around? Wait and see.

Very thorough paper on optimization techniques when dealing with GPUs. Can be a useful reference or starting point to then dig deeper. Should also help to pick the right technique for your particular problem.

A good reminder that depending what happens in the kernel, the I/O time you were expecting might turn out to be purely CPU time.

Good list of things to keep in mind when thinking about performances. Of course, always measure using a profiler when you want to be really sure.

Interesting way to approximate how loaded a system is.

Interesting tale and exploration on how a change in includes impacted cache misses. This is sneaky (and solved with more recent compilers).

The claim is huge. The story doesn't quite say how much is really about Elixir and how much from the revised architecture. That being said, going for something like Elixir has definitely an impact on the architecture... could it be that it pushes for better patterns?

Another partial quote which led to misunderstanding. One should indeed think about performances early on.

Obvious advice perhaps, but so easily forgotten somehow...