-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance when computing single indexes on RSI with large datasets #114
Comments
I added an implementation which is about 3x faster than standard Trady RSI. It can be better if I can incrementally update the points
I've tested this vs. Trady RSI and it gets results after the stabilisation period (about 100 bars to stabilise when Period=14) similar to the built-in Trady RSI. |
Update. I have an implementation of RSI which is about 1,000 times faster than the Trady built-in RSI, but requires that you update/add a single point via the AddOhlcv() method. This is therefore not immutable and breaks Trady's immutability which also makes Trady thread safe, but I'm willing to take the risk for the extra speed that this offers. It makes some backtests I'm running which rely on RSI considerably faster. Here's the code :) (sorry about the reflection hax but these fields are not accessible and probably for good reason)
Usage
|
Hey there!
First of all, this is a great library and wanted to thank you for creating it. I'm using Trady in an experimental backtesting engine for cryptocurrencies with charting visualisation by SciChart, which when I'm done I may open-source the backtester / visualisation to show how you can create a trading app with Trady.
Now I make heavy use of the Rsi indicator and for backtesting I want the best possible performance. It currently takes 3 minutes to backtest a years-worth of hourly bars and this is too long.
I optimised my code to compute only the latest index on new bar added to the backtest, like this:
However, when there are about a thousand bars this results in nearly 1 million calls to GenericMovingAverage.ComputeCumulativeValue
I wonder if there's a way to improve the performance of this? For example a 14-period RSI only needs to compute 14-periods of a generic moving average to get the latest values.
Or ... a way to create some kind of a overload of indicator that allows you to Push or update a single IOhlc to the indicator
The text was updated successfully, but these errors were encountered: