Today, in the volatility, I got some of my old NT performance issues back (60 second lag). Now - It's either give up on platform for the last time, or try to figure it out, pretty much now. So, I fire up NT utilisation monitor whilst this is all going on. It says (and has said somtimes in the past), that one of my indicators is in the top 4. This actually makes sense a bit, as it's on the 2 most active charts in my workspace and updates on a price change level. BUT, this indicator is a slightly modified RSI! Nothing complex. In fact, so simple I in the past ignore the utilisation monitor results and considered them bogus. Today, I went through the code, line by line. The easy way to test for the problem code was to simply put a 'return;' in front of each block, starting at the very top of 'OnBarUpdate' and see if the latency for this indicator improved. As expected, as the top, it totally disappeared from the utilisation list. So, I start moving the 'return;' down, code block by code block until I find the latency of the indicator increase. Now, I find the problem block. But, it makes no sense, so I confirm many times, moving the returns around in the code, restarting platform, etc. Each time this block is executed, the indicator resources go through the roof.
So, here is the block. Simple as it is. I have no idea why this particular piece of code would cause such a dramatic performance issue, but I ask for comments from NT staff to educate me, please...
[CODE}
///////
return;
// colour fast plot above/below ss
if (Default[0] > ss[0])
PlotBrushes[0][0] = upColor;
else if (Default[0] < ss[0])
PlotBrushes[0][0] = downColor;
else
PlotBrushes[0][0] = neutralColor;
[/CODE]
if the return is included as shown. Code is fine. Move the return below the last line and the indicator suddenly becomes a top 3 resource user. How come!? Is changing a plot brush really that expensive of an operation?
Thanks.
Comment