Profiling Strategy and a Case

To profile a program, you need to run it. Nonetheless, running the whole program in profiling mode can generate a lot of data that you do not care about, and this adds noise to what you might be trying to understand. A good strategy to leverage if your program has unit or functional tests is to use them to profile your code. They are little scenarios that can be very useful when you want to obtain profiling data.

Using tests is a good strategy for a curious and naive first-pass at profiling. Though there is no way to make sure that the hot spots seen in the unit/functional tests are the actual hot spots that an application encounters in production.

This means that a profiling session must be executed with the same conditions as the production environment and with a scenario that mimics what is seen in this environment. It is often a necessity if you need to push your program optimization further and want to achieve perceptible and valuable gains.

Carbonara

I wrote a little library called Carbonara that computes time series. To check its performance and possibly make it faster, I profiled it using one of its unit tests named test_fetch. The test is pretty simple: it puts data in a time series object, and then fetches the computed aggregation result.