03-26-2018, 07:14 AM
I am currently doing a major rewrite of the event system within the codebase. There are a few reasons for doing so: it allows for new features like advanced order types, a faster backtester, better event streamline and a lot more. I currently have an early version of a new backtester, you can find it in the PR for 0.6:
https://github.com/askmike/gekko/pull/1850
Since this commit the API endpoint has changed for doing a backtest. Instead of passing a data object that defines what data you want you now need to add a new plugin to the config called the "backtestResultExporter", in here you can specify what data you want to be returned. See here what the UI is passing. You can also specify indicator results! Native indicator results are available, async ones are coming asap.
On top of that, this is what I am planning to do:
- We can actually optimize a lot of things if we know the backtest doesn't need to return any candles / indicator numbers / trades, not just on at the end before we send out the result over the REST API, but even inside the gekko stream.
- We can drastically increase performance of async indicators by pregenerating all their outputs in batches. This means we don't have to ask TA-lib every candle, but just once every X candles (as much as we can store in memory).
If anyone has more ideas please throw them here since I am changing it right now anyway
https://github.com/askmike/gekko/pull/1850
Since this commit the API endpoint has changed for doing a backtest. Instead of passing a data object that defines what data you want you now need to add a new plugin to the config called the "backtestResultExporter", in here you can specify what data you want to be returned. See here what the UI is passing. You can also specify indicator results! Native indicator results are available, async ones are coming asap.
On top of that, this is what I am planning to do:
- We can actually optimize a lot of things if we know the backtest doesn't need to return any candles / indicator numbers / trades, not just on at the end before we send out the result over the REST API, but even inside the gekko stream.
- We can drastically increase performance of async indicators by pregenerating all their outputs in batches. This means we don't have to ask TA-lib every candle, but just once every X candles (as much as we can store in memory).
If anyone has more ideas please throw them here since I am changing it right now anyway