Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Well, the Express Edition of Visual Studio is free available (after registration), but (as far as I know) that version doesn't support the 'performance profiling'.
I'm not an Visual Studio expert (not even an intermediate user lol) but I looked at your question. If I understand it correctly, you where wondering if the strategy would be an continuous drag on a system resources?
Because I don't have your strategy (or settings for that matter), I did the following in NinjaTrader while Visual Studio was profiling in the background:
1. Started up NinjaTrader 7.0.0.20 (empty workspace),
2. Opened a 5 minute chart (with 30 days of data),
3. Connected to Interactive Brokers,
4. Let the chart update in real-time for a few minutes,
5. Added multiple indicators (with CalculateOnBarClose on false),
6. Let the chart and it's indicators update in real-time for a few minutes,
7. Exited NinjaTrader.
The idea was that, if multiple indicators lead to higher CPU usage, you would see an higher level of CPU usage after adding the indicators than you saw before adding the indicators. Please see the screen with the CPU chart from Visual Studio: I can't see any noteworthy higher CPU usage after adding of the indicator. I've also added a chart which shows wich indicators I put on the real-time chart.
But I do not know how to read the various processes as is demonstrated in the wiki article, so perhaps these findings are biased or so.
Perhaps @MXASJ or @gomi can provide some useful insights.
for me it was more a basic question if this indicator (VolatilityStop from below) would use the high loading- (initialize-) power also in permanently running stat in strategy usage.
because i am not shure WHY its using so long loadingtime.
just to understand a bit more of those coding-stuff.
MXA says this :
I have strats that take about 10 seconds to initialize, but then consume very liitle.
so i think that answers also for my Q : it may be the initializing process only. - but its not tested yet.
if you like to ad the VolatilityStop (see in the first post) in your testing-setup + watch whats going on - that would be interesting!
maybe i do a small strategy with the VolatilityStop later to also test it with strategy running.
well - if YOU are willing to do more tests ! -- i dont have VS on my end ... mxa also not - he has only a small version.
testing could be done with pressing F5 to reload all the stuff in the chart.
it can be cpompared with having one chart with those several indicators in + press F5
and having another chart with tose several indis PLUS the vola-stop in ther + press F5
and watch the graohs --- just as idea
There are specific NinjaTrader methods that cause problems with CPU usage
(1) The worst problem is caused by custom plots that execute heavy calculations. The reason is that the plot is recalculated for every incoming tick, even if an indicator is set to CalculateOnBarClose = true; Proper coding with NInjaTrader requires that custom plots are kept as slim as possible.
(2) Some of the Draw() Methods of NinjaTrader are badly implemented, so you need to reduce the lookback period of any indicator that draws on the chart. I have had huge problems with DrawRectangle(), DrawDiamond() and DrawArrowUp() etc. To reduce the lookback period of the indicator, you can just add a line to check for the date.
(3) Some of the other methods such as MAX() ,MIN() also cause problems.
(4) You can reduce the CPU load by putting some of the indicator code into a bracket after FirstTickOfBar
These are the principal case that I have encountered. Of course you can use the sophisiticated methods of Zondor to further speed up your code.
OK - i made some simple strats with the indicator for testing :
it plosts 2 arrow if we have a cross of the Close above / below the VolaStop
- ____Vola_Bucks_02.cs = incl. the Original VolatilityStop + NO ploting
- ____Vola_Bucks_01_Plus_Plot.cs = incl. the Original VolatilityStop AND ploting on the chart
- ____Vola_Bucks_01_Minus_Count..cs = incl. the fast variation of the VolaStop - inpired by Fat Tails ideas - for testings only - + NO ploting on the chart
- VolatilityStop_Test_Tails.cs = here i replaced the variable "counter" in the MAX / MIN - calculations with a fix variable and it loads superfast now + used it in the strategy ____Vola_Bucks_01_Minus_Count..cs
The idea was if the strategys are very different compared to eachother in
1 - loading
2 - during live-running
looking at cpu-usage + analyses in VS
and if its possible to see wich section is responsible for this. ( hot lines or so ... )
as said Jura or other VS-owners , if you have fun with doing this or find it useful somehow.
. Have no 
at all.
