It's a solution for a problem long gone. SPAs should be the exception for highly interactive applications not the norm. Most web applications don't need to be a SPA and would be better off without being one.
When everything obvious fails... there are still optimisation tricks available for your databases.
More interesting design ideas in uv. Didn't know about the dashmap crate they're using here it looks like a nice one too.
A very comprehensive view of Python memory consumption and the speed of common operations. Some of the numbers are higher than I expected.
Unsurprisingly, this is mostly not related to the use of Rust. The design choices are what male uv so fast.
Excellent resource for keeping an eye on performance issues in your codebase. It's very C++ oriented but most of the insights can be generalised to other ecosystems.
Nice explanation of what Bloom filters are for and how they work.
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...