02-07-2018, 03:56 AM
> - logging: Yes, disabling logging increases performance but not that much. From ~9s to ~7.8s using the same data. I use a simple this.debug true/false for my own stuff to enable or disable debugging messages since one doesn't seem to be able to control the default debugging state within strategies.
Can you try setting config.silent to true, this disables literally all logging, setting config.debug to false will additionally noop your strat's log function (if you have one). Keep in mind that logging might not effect your situation very much, but it might very well on other types of systems.
> Also -- just getting all the data for over 1 years of data only takes around ~200ms (or ~450ms if order by id desc) when querying the db manually (with bad settings). Just doing a large READ doesn't take that long even if number of rows is over 1 million. One would also ofc get all the data in a single query and not query the db all the time. With that in mind i really don't see how SQLite could be a culprint during a backtest since we only got (or should have) a single and simple SELECT?
Gekko doesn't query everything at once, but in batches. This way Gekko does not need to store all the candles you need in memory (which will be hard on servers and embedded devices). You can configure the config.backtest.batchSize to change this.
> From ~9s to ~7.8s using the same data.
Was this using your perf check? What candleSize and what dateRange was this?
Can you try setting config.silent to true, this disables literally all logging, setting config.debug to false will additionally noop your strat's log function (if you have one). Keep in mind that logging might not effect your situation very much, but it might very well on other types of systems.
> Also -- just getting all the data for over 1 years of data only takes around ~200ms (or ~450ms if order by id desc) when querying the db manually (with bad settings). Just doing a large READ doesn't take that long even if number of rows is over 1 million. One would also ofc get all the data in a single query and not query the db all the time. With that in mind i really don't see how SQLite could be a culprint during a backtest since we only got (or should have) a single and simple SELECT?
Gekko doesn't query everything at once, but in batches. This way Gekko does not need to store all the candles you need in memory (which will be hard on servers and embedded devices). You can configure the config.backtest.batchSize to change this.
> From ~9s to ~7.8s using the same data.
Was this using your perf check? What candleSize and what dateRange was this?