Expert advisors and the tick processing queue
Posted: Sat Oct 31, 2026 8:45 pm
An expert advisor runs its logic on every incoming tick. If the code takes longer than the interval between ticks, the next ones queue up. The result is that decisions are made on stale prices.
On a calm market this hardly matters. During a spike, when ticks arrive by the dozen per second, a slow advisor can fall seconds behind and place orders at prices that no longer exist.
The cause is usually heavy calculations inside the tick handler: loops over large arrays, repeated indicator calls, file operations, or web requests. Moving that work to a timer, caching results, and calculating only on new bars can reduce the burden.
A simple diagnostic is logging the time taken by each tick call. If anything regularly exceeds a few milliseconds, there is room for improvement.
Several advisors on one platform compound the problem since they share a thread, so one slow script delays the others.
Has an advisor ever fallen behind during fast movement, and how was the issue discovered?
On a calm market this hardly matters. During a spike, when ticks arrive by the dozen per second, a slow advisor can fall seconds behind and place orders at prices that no longer exist.
The cause is usually heavy calculations inside the tick handler: loops over large arrays, repeated indicator calls, file operations, or web requests. Moving that work to a timer, caching results, and calculating only on new bars can reduce the burden.
A simple diagnostic is logging the time taken by each tick call. If anything regularly exceeds a few milliseconds, there is room for improvement.
Several advisors on one platform compound the problem since they share a thread, so one slow script delays the others.
Has an advisor ever fallen behind during fast movement, and how was the issue discovered?