p403n1x87@heliopolis:~/tags/optimisation$
$ ls -lt tags/optimisation/
CPython now ships its own sampling profiler, free-threading is going mainstream, and coding agents have started reading profiles. In this post I look at where Python profiling stands today, compare Tachyon, py-spy, Scalene and Austin, and go through what's new in Austin 4.1.
Coding agents are fast becoming the main generators of new source code, but they are also being used for code review, finding and fixing bugs. How can they be used to the best extent to discover and fix performance issues?
In this short post I will try to convince you of how easy it is to find performance issues in your Python code and how you should develop the habit of profiling your code before you ship it.
If you want to be sure that your applications are working optimally, then sooner or later you will end up turning to profiling techniques to identify and correct potential issues with your code. In this post, I discuss some of the current profiling tools and techniques for Python. The official documentation has a whole section on the subject, but we shall go beyond that and have a look at some alternative solutions, especially in the area of sampling profilers.
What does the principle of locality of reference have to do with prime numbers? This is what we will discover in this post. We will use the segmented version of the Sieve of Eratosthenes to see how hardware specifications can (read should) be used to fix design parameters for our routines.