ChartControl.FirstTimePainted/LastTimePainted performance issues while debugging

[carnitron]

These two routines appear to get increasingly slower the longer you stay paused in the debugger, if you have the point in time at which you paused the action visible in a chart window.

To reproduce:

1. Call these routines 1000 times in a loop:

ChartControl.FirstTimePainted
ChartControl.LastTimePainted

2. Break in the debugger and wait for 5 minutes.

3. Resume.

4. Get the point in market time where you paused in the debugger to appear on the chart window.

5. Break in Visual Studio and look at the performance spent on these routines, it will dwarf everything else.

Cheers.

[NinjaTrader_Gaby]

Hello carnitron,

Thank you for your note.

From testing, we are seeing the properties are able to be looped over with normal resource usage after the break is continued. At the bottom of this post I've included a video demonstration.

While there does seem to be an initial spike in CPU usage when the break starts, it returns to normal after continuing. I tested this out on the latest version 8.1.3.1, and on a previous version 8.1.1.7. We will keep a note on this, but this appears to be expected behavior and unrelated to the latest release.

In the video, the 5 minute wait time is edited out. I highlight the breakpoint event in is VS and you can see the initial spike at the start of the breakpoint which returns to normal even during the duration of the break.

https://app.screencast.com/S40fIqBbVrto9

[carnitron]

After watching your video, I realize I probably left out a crucial piece of info. I'm down on the 1s time frame.

When on the 1s, if you wait 5 minutes while broken, several hundred time points get "eliminated" from the chart view. I.e. NT8 will not draw the seconds that elapsed while broken, but instead causes the times before and after the break to abut one another on the chart, as if the broken seconds never occurred.

This would not be an issue in your example, b/c there are really only maybe 5 time points that get eliminated this way, b/c you are the 1m.

I suspect that FirstTimePainted and LastTimePainted are iterating internally somehow, so that they become linearly more expensive with each passing tick when this debugger-induced time gap is on screen.

So if the chart normally displays 60 seconds, it is now actually displaying a span that is those 60 seconds plus 300 seconds from the 5 minute gap zone that is contained within the time frame that is being displayed, but is not being drawn on screen.


This was an issue for me, b/c sometimes I'd pause in the debugger for 10+ minutes, and when I would resume, the chart would freeze, and never come back. This is b/c I am doing a lot of drawing, and when this gap zone was on screen, I'd be drawing for an artificially huge number of ticks, causing me to hit FirstTimePainted and LastTimePainted 5-7k times in total for the whole screen, each time the market data advanced a tick. Even on my super fast machine, the system could not keep up. However, if I only paused in the debugger for maybe 3 minutes, I could slowly get the gap zone off screen, and everything would be smooth again.

I have fixed the problem for myself, by calling FirstTimePainted and LastTimePainted once per tick, which has led to everything becoming butter smooth again.

Still, it feels like it might be worth NT8 investigating the FirstTimePainted and LastTimePainted implementation, b/c maybe there are easy fixes. Like, if nothing else, having those returns internally cache their results for the given tick, as I do.