Actually I was more considering it in the live environment if/when the strategy graduates from back testing . It would be useful to be able to visually see what the strategy is doing for monitoring purposes and peace of mind of those who might use the strategy but have not developed it.
I understand we can already see buying and selling using the brokers own platform. However you can't see any custom indicators, support lines or other things we can plot on the backtested charts that might have caused the strategy to enter or exit a trade.
backtrader takes a dual approach to the problem. This is controlled with the runonce (boolean) parameter to either a instantiation of Cerebro or to cerebro.run like in
The default is runonce=True
cerebro = Cerebro(runonce=True) # or False
cerebro = Cerebro()
cerebro.run(runonce=True) # or False
This could be called a pseudo-vectorized of half-vectorized approach. Built-in operations feature a once method which calculate things in batch mode in a tight inner loop.
Data feeds are fully pre-loaded
Indicators (and sub-indicators thereof) are pre-calculated in batch-mode
Then, the Strategy instance(s) are run step-by-step
Being the goal to offer an increase in speed, but still allow for fine grained logic in the next method of the strategy
Rough calculations indicate that it is somehow between 20-30% than runonce=False
Drawback: Because indicators are precalculated (and therefore the buffers are preallocated), the data synchronization mechanism cannot pause the actual movement of a data feed when synchronizing the timestamps for the strategy, keeping the buffers to the final same length. This has no actual impact for backtesting but because matplotlib expects all things to have the same x length for plotting, it may not be possible to create a plot of the backtesting.
Drawback 2: The implementation of this mode prevented that some indicators can be fully defined in recursive terms with a single formula. A choice had to be made between having this or having the recursive formulas.
Nice Thing: If a user implements a custom Indicator and only provides a next method (intented for step-by-step, see below), the code automatically detects it and will still pre-calculate the indicator using the next method instead of the missing once method. The calculation loop will not be so tight as it could be, but users don't have to worry about implementing once
This is a 100% step-by-step mode. Also named next because only the next method of the different indicators, strategies et al., play a role.
Everything is calculated one step at a time. The reason being the addition of data feeds which would be providing the data points one step at a time (not necessarily live feeds, it could have been reading out of a socket from a database connection).
If cerebro is run with preload=False (disable the preloading of data feeds) it will switch to this mode.
I managed to get my optimizations to run as quick as optstrategy by subclassing Cerebro and pulling out some stuff out of run() and addstrategy() into different functions (one to initialize data loading, and another which gets re-executed from outside the class for optimization).
I also manage multiprocessing from the outside.
Do you mind to share some code? Or kind of a layout of what and where was implemented in more details?