performance issue - Code comment, please

[pjsmith]

Hello,

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.

[pjsmith]

To add further confirmation, I left this block of code commented out in my code - All other code original. Issue is gone (for this indicator, at least).

I have some other indicators that have similar plot colour changes. I'm going to comment them and see if it has such a dramatic effect, too...

[NinjaTrader_Jesse]

Hello pjsmith,

Assigning a new brush to each bar will be resource intensive as you are using many brushes. There is actually an upper limit for brushes which is around 65000. For an item which needs to color every bar we generally suggest to use OnRender for that purpose instead of assigning a new brush for each bar. PlotBrushes is most useful when used for conditions which infrequently become true and OnRender would be used for items which are always or very frequently true.

Using a series and OnRender would likely be the most efficient solution or to mark a specific value per bar like -1,0,1 and then use OnRender for coloring based on that input. In that use case only 3 total brushes would be used instead of adding a new brush per bar.


I look forward to being of further assistance.

[pjsmith]

Thanks for the reply. I was aware of the brush limit.

New brush? Isn't it the same, brush, re-used? The colours are fixed. One of 3 brushes. My god though, if this has such a significant performance hit, you really should be pushing this knowledge out there as it would likely solve a ton of the complaints you get re performance!

[NinjaTrader_Jesse]

Hello pjsmith,

No this is a series, you are assigning a new brush to each new bar:

PlotBrushes[0][0] = upColor;

You will have multiple duplicate colors in the series in your use case but this would add a new brush each time you set the series index. We do provide education where possible to use OnRender instead for performance reasons.

Please let me know if I may be of additional assistance.

[pjsmith]

OK - I'm going to code all these into OnRender. I take it the same performance hit would be caused by BackBrush? I seriously cannot believe how much of a hit this has!

[NinjaTrader_Jesse]

Hello pjsmith,

Correct, that is also going to apply per bar so if you will be doing this on every bar it would be beneficial to instead do that from OnRender.

I look forward to being of further assistance.