forex-scalping.com

Python bots and the pause nobody planned

Python is popular for trading bots. It's quick to write and has great data libraries. Its runtime also has behaviors that matter for timing.

Garbage collection occasionally pauses the program to clean memory. Usually the pause is a millisecond. With large data structures, it can reach tens of milliseconds, at random moments.

The global interpreter lock means only one thread runs Python code at a time, so a heavy calculation in one thread can delay another that's handling price updates.

Slow functions in the hot path, such as parsing a large JSON message or recalculating an indicator over a long history on every tick, add up under load.

Mitigations include preallocating memory, avoiding creating many temporary objects in the main loop, using efficient libraries for numerical work, and separating the price-handling loop from heavy analysis.

Measuring is essential. Log the time between receiving a tick and sending an order, in microseconds, and look at the distribution. The median might be fine, while the 99th percentile hides the pauses.

For strategies where tens of milliseconds matter, a compiled language may be the better tool.

At the 99th percentile, how long does the bot's decision loop take?

Python trading bots that connect to MetaTrader through the MetaTrader5 package or to brokers through APIs can pause unexpectedly for various reasons. Garbage collection, network timeouts, blocking calls or the operating system putting the process to sleep can all cause delays. For a scalping bot, a pause of even a few seconds can mean missing an exit or reacting to stale prices. Monitoring the bot's loop timing, by logging how long each cycle takes, helps detect pauses. If a cycle takes much longer than usual, the bot can log a warning and check its positions before acting further.

I measured this in a small Python bot I ran against a demo account, and the median decision time was just 1.8 milliseconds. The 99th percentile, though, was about 41 milliseconds, and a couple of ticks took over 200. At first I assumed it was my network, but when I added timestamps at each stage I found it was the garbage collector firing while the bot built a large list of recent ticks on every update.

I fixed most of it in two steps. I replaced the growing list with a fixed-size ring buffer, so memory was allocated once, and I moved the heavy indicator calculation into a separate process that sends the result over a queue. The 99th percentile dropped to around 9 milliseconds.

The thing I'd stress is to log the whole distribution and not only the average. Everything looked healthy until I plotted a histogram, and the long tail was where my occasional bad fills were hiding.