[gmrple]

Next, if you really want to time something fast you should probably know about cache. In a modern computer there are levels of memory. For now we’ll say we have 3 levels: cache, ram, and a hard drive. Cache is small but very fast, it is the closest level to the CPU. RAM is bigger but slower and the hard drive is much much slower. Because the cache is small the computer has to pick what’s in it. At program load the cache will be full of information related to whatever was running before you. After you run you will have left some information in the cache which will not need to be fetched from slower levels of memory. Unless your usecase is to run your test code repeatedly very quickly, you should be wary of timing multiple calls in fast sequence as the later calls will execute faster due to the cache being primed to execute your code.

[hyperpape]

Great point. In addition to caching, there's potential for branch prediction effects.

This is why the JMH samples warn against including loops[0] of the operations you're trying to measure, and have an API that's designed to avoid the programmer having to every write their own looping code.

[0] https://hg.openjdk.java.net/code-tools/jmh/file/7bc6011260aa...

[stygiansonic]

Great point about using JMH. As of JDK 12, it’s included in the SDK: https://openjdk.java.net/jeps/230

What’s the equivalent of JMH for Python?

[hyperpape]

I'm afraid I don't know, I really don't have any particular knowledge of performance engineering in Python.

[pvg]

I'm not sure the JMH is meaningfully included in the JDK for others to use. The JDK happens to come with some JMH-based benchmarks in the source tree, that seems to be about it.