7 articles
Imran Nazar recreated a JavaScript animation demo on 1982 hardware and wrote up every decision along the way: 6510 assembler, fixed-point math with no floating point available, a CPU bug turned into a cosine lookup. When he lands at 30fps, he can tell you exactly why without running it. It's very cool.
Kirk Pepperdine has released gcsee-jma, a GC analysis tool for Java. Kirk's been a leader in performance analysis for Java for decades, and a tool from his work is welcomed. It's got excellent, clear, fast features, and looks to be incredibly useful.
Christian Rackerseder makes the case that developer experience is a performance feature. The stronger version of his claim is that developer experience is an epistemic feature. Good performance is just one of the things that falls out when your team can finally see what it has been shipping.
Dragonfly is a multithreaded ground-up reimplementation of the Redis wire protocol, described as being designed to scale vertically where Redis can't. The interesting thing is that Dragonfly is selling itself as "in-memory infrastructure for caching, feature stores, and job queues," which is the IMDG shape from the cache side of the river and a quiet admission that the cache framing was always too narrow.
TypeScript 7.0 Beta represents a fundamental architectural shift for the language, with the entire compiler rewritten in Go rather than bootstrapped TypeScript. The rewrite delivers approximately 10x performance improvements over TypeScript 6.0 through native code execution and shared memory parallelism, while maintaining strict semantic compatibility with the previous version.
Optimization isn't a single measurement and a fix. It's whack-a-mole: find the loudest problem, fix it, then look at what the problem was hiding. Jonathan Vogel's second installment in his Java performance series shows this process live, with JFR recordings and flame graphs - including a contention bug that was completely invisible until he pushed the concurrency high enough for it to matter.
Junior programmers mess up paradigms because they think they're more experienced than they actually are. They end up blaming the system for not working the way they think it should. I trusted the wrong thing, just like a junior programmer: I assumed my tests were wrong, my results were wrong, that I was wrong, and I was - but the error was in the location of the problem.