Indicator Speed-up

In my opinion, the automagic indicators are one of TuringTrader’s best features. Unfortunately, this convenience came with a little bit of a performance hit, which became obvious when running indicator-heavy strategies. This week, we have done some major re-factoring of the indicator mechanism, leading to a dramatic increase in indicator performance.

Background

TuringTrader’s automagic indicators make the use of indicators as simple as a function call. Under the hood, TuringTrader calculates a hash value for each indicator use. This hash value is comprised of the following components:

• input data series
• indicator parameters
• call stack

With this hash value in hand, accessing indicator objects becomes as simple as a dictionary lookup.

As far as I know, C# offers two ways of retrieving the call stack:

• System.Diagnostics.StackTrace
• Exception.StackTrace

What both methods have in common, is that they are incredibly slow. As a result, our automagic indicators become a burden when the strategy: (1) instantiates a bunch of indicators, (2) runs on many instruments simultaneously, and (3) requires optimization. As luck would have it, we’ve been working on such a strategy: Laurens Bensdorp’s MRL strategy.

New ways

This week, we have abandoned the idea of retrieving the call stack in a single step, and through one of the methods mentioned above, we are using System.Runtime.CompilerServices, namely the CallerMemberName and CallerLineNumber attributes, to push the majority of the effort from run-time to compile-time.

Further, we have added functionality to incrementally calculate hash keys, and pass them through the hierarchy of indicators.

And why are we mentioning this? Because otherwise you wouldn’t have noticed! The good news is, that all user code should be unaffected by this change.

Happy coding!