Note the sleight-of-hand here, the author says: > I read this article [...] It presents an example program and shows how to run it with several time-worn Pyt

Note the sleight-of-hand here, the author says: > I read this article [...] It presents an example program and shows how to run it with several time-worn Python profilers. [...] I wondered if I would be able to get more useful information from Scalene, a profiler I co-wrote. They then proceed to tell how Scalene pointed out that "num / fact" is the slowest part, and used it to optimize the code 5000x. A reader who is not careful might think that Scalene actually does something that "time-worn Python profiles" cannot do. This is not the case. Reading original Martin Heinz' article, both line_profiler and pyheat (from "Digging Deeper" section) gave exactly the same insight -- that "num / fact" is the slowest part. So there was nothing special in the Scalene compared to all the other profilers. The reason Emery Berger got 5000x optimization is because they changed the algorithm (and got the different answer), something that was out of scope in the Martin's blogpost.