Parallel For AccessViolation: Attempted to read or write protected memory

[habibalex]

I have some indicators that use Parallel For loops to increase speed of drawing on the chart. Unfortunately this breaks ninjatrader8 and it freezes with a AccessViolation exception: Attempted to read or write protected memory on v8.0.0.19. When I change the Parallel.For to regular for loops I do not notice the error. How would you suggest I fix this? I need the Parallel.For as I am looping through about 40000 objects per chart render and the order of the render is not really relevant. I use a predefined set of Brushes generated in OnRender and do a lookup of those from a list. Generating these color in each loop is not efficient based on my previous tests.

for(int i = 0; i < 10; i++){
                    redGreenColors[i]= new SharpDX.Direct2D1.SolidColorBrush(RenderTarget, new SharpDX.Color4(new SharpDX.Color3( 0, (i/15.0f)+.2f, 255),.8f));
                    redColors[i]= new SharpDX.Direct2D1.SolidColorBrush(RenderTarget, new SharpDX.Color4(new SharpDX.Color3((i / 9.0f) , 255, 255),.8f));    
                    blueColors[i]= new SharpDX.Direct2D1.SolidColorBrush(RenderTarget, new SharpDX.Color4(new SharpDX.Color3( 255, 255, (i / 9.0f) ),.8f));    
                    greenBlueColors[i]= new SharpDX.Direct2D1.SolidColorBrush(RenderTarget, new SharpDX.Color4(new SharpDX.Color3( 255, (i / 15.0f) + .2f, 0),.8f));    
                    }

Parallel.For(ChartBars.FromIndex,ChartBars.ToIndex, i =>
                {
...do stuff...
});

[NinjaTrader_Jesse]

Hello habibalex,

There is no suggested means to use multithreading in NinjaScript, NinjaTrader is already a multithreaded application which takes internal steps to manage resources used by NinjaScript in the multithreaded environment.

By introducing new threads you no longer share the same context and introduce multithreaded errors. I would have no suggestion for using parallel loops from NinjaScript, I could only suggest to use standard loops and to try and come up with a more efficient pattern.

You mentioned this happens for the chart render and by that I assume you are using OnRender for all of this logic, is that correct?

Do all 40000 objects need to be rendered in the same visible chart area?

If not, you are likely not using OnRender efficiently based on the description. If you need to loop 40000 times for every render pass that logic will be slow no matter how it is used because that is a large number of iterations happening and will be impacted by being called very very frequently. Generally speaking the render pass is a very bad area to do heavy calculations or long loops, could this instead be accomplished at a slower rate from OnBarUpdate and then just rendered for the visible bars? There are likely improvements that could be made in your calculations, moving to using parallel is not something I could suggest pursuing as there is no support for multi threading.



I look forward to being of further assistance.

[habibalex]

It's a short time frame chart looking at depth. There are no heavy calculations that occur in OnRender other than some minor relative scaling. In addition, most of that relative scaling code has also been pre-calculated for the next loop to minimize it's impact in the current OnRender. I have thought about the architecture of this code to optimize it. All other calcs related to data are done as the chart receives data in OMD and OMDepth. Ninja still shows sluggishness which is why I introduced the parallel.for and saw very significant OnRender improvements. So much so that I could use the TickRefresh indicator at < 20ms intervals with minimal effect on performance unless there was a significant news event (in which case i would experience significant lag most likely related to OMD / OMDepth). Ninja is multithreaded in some sense, but the same OMD are shared between different charts which makes it perform essentially singlethreaded as suggested by others on this forum. OMDepth lag may be due to the way I have coded, but without a good way of testing OMDepth w/ an external connection, I have to conclude that the lag is caused by Ninja's architecture. Just FYI, Bookmap doesn't appear to suffer from these issues

[NinjaTrader_Jesse]

Hello habibalex,

Thank you for the reply.

Yes the speed of the render will ultimately depend on what you are doing and how efficient that is, based on the description provided so far it sounds like your logic would need to become more efficient rather than trying to distribute the work in an incorrect way for the environment being used.

You also mentioned the TickRefresh being used, this item is known to cause serious performance issues. If you choose to use the addon, you will see performance degradation when more complex scripts are used or when high volatility happens. This is not suggested to be used and it would be expected to see slowness in general if you have this imported. I would suggest removing this addon while you develop your script so you can see the actual performance of your rendering.

I look forward to being of further assistance.

[habibalex]

I removed the parallel for and the onrender performance seems better in v19 than previous version. Also no crashes so I'll probably keep it as is. I haven't been using tickrefresh, but w/ the parallel for I was able to w/ no lag. I was mainly using that indicator for short term trades in CL which needed a chart refresh rate of < 50ms to display data 'continuously'. The main reason I moved away from it was because I implemented similar code as a SuperDOM column and created my own charts directly on the DOM which has much faster native updates.