Indeed this. It's not only about payload size, it's also about CPU consumption. Our profession is still assuming too much that users will get faster CPU on a regular basis.
This is nice to see a new benchmark being published. This seems to follow real life scenarios. We can expect browser engines performance to increase.
A response to "The Hunt for the Missing Data Type" article. There are indeed potential solutions, but they're not really used/usable in the industry right now. Maybe tomorrow.
Indeed, graphs are peculiar beasts. When dealing with graph related problems there are so many choices to make that it's hard or impossible to come up with a generic solution.
Interesting take even though I'm not sure I buy it completely. This is an interesting pledge for aiming at power efficiency and squeezing performance out of software.
Interesting library if you got to do a lots of heavy analysis work with strings.
This is indeed an odd situation... there is no good explanation about why this is like this.
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...
OK, this could be big for Python. Let's see how they execute this plan. It carries some risks as well, but they seem well aware of them.
Interesting optimization on this somewhat common data structure.
Unsurprisingly, it's not as simple as it sounds. Type hints in Python can be used for various reasons but performances is rarely the main motives. It'd need other adjustments to the runtime. People are working on it, and this article is an interesting dive on how things work under the hood.
This compilation technique brings very interesting results. Hopefully should find its way in some JIT compilers.
Interesting research turning to genetic algorithms to optimize bytecode handler dispatchers.
Deep dive on a proper benchmarking and implementation for 1M task on the Erlang runtime. Clearly the previous benchmark had room for improvements.
Nice and thorough workshop on vectorization, where it comes from, what it can do and how you can write code which is easier to vectorize for the compiler.
Doesn't give the whole picture (memory isn't the only important parameter) but interesting results nonetheless. A few surprises in there, Java and C# do much better than one might assume for instance.
Interesting take. Will it lead to paying more attention to performance in software? Will it be the rise of the specialized CPUs? Time will tell.
Good explanation of how flame graphs are produced and how to read them. Gives a few tips on what to look for to optimize.
Interesting exploration on the performance of SSDs regarding write patterns. Turns out sequential IO is still a thing, just for a different reason than with good old HDDs.
Very interesting to see that move to owned hardware... turns out that not only the invoice is smaller in their case but the performances are much better as well.
Nice set of tips, I knew a few but not all of them. The discussion around CTEs is interesting.
Nice exploration of false sharing on performances in several hardware scenarii. A couple of surprises along the way.
Shouldn't come as a surprise if you paid attention to C++ evolutions for the past 30 years. We're now reaping the fruits though, so it's really become easy to keep both options in sight when designing. This is especially important for performance sensitive code.
Nothing really new here (apart from the "how easy it is these days!")... Still it needs to be reminded on a regular basis. :-)
Nice post explaining the common algorithms used for load balancing. Each having their own trade offs of course. Well done with tiny simulations.
Polars really looks like a nice alternative to Pandas with a nice upgrade path from data exploration to production.
Nice walk through for a use of PyO3 to make some Python code much faster. Nice to see how useful py-spy turn out to be in such scenarii as well.
Very interesting conversation between Uncle Bob and one of the recent critics of his work regarding performance. I like how he admits some faults in the way he presents things and try to improve for later rather than trying to be right. Some people should learn from that. There's clearly a tension between performance and what is described in Clean Code, it'd be pointless to deny it.
perf now available also to Python programs. This definitely can be useful for proper profiling.
Interesting position from AMD regarding the race on the next super computers. They're all being caught up by energy efficiency so it'll need to be addressed both at the processor architecture level but also at the software architecture level. How we design our computing tasks will matter more and more.
A bit of a sarcastic tone but a few good point in there. Also shows interesting alternatives to C++ to squeeze every ounce of performance out of your code whatever the platform it runs on. Of the three options explored I knew only about Numba really.
Excellent analysis and explanation of the stutter problem people experience with game engines. It's an artifact of the graphics pipeline becoming more asynchronous with no way to know when something is really displayed. Extra graphics APIs will be needed to solve this for real.