CPU usage: minimized windows vs. other open workspaces

[Trader_55]

Hey there...

I know that if you have more than one workspace open, then indicators will still continue to calculate on those charts in the background and will consume CPU cycles, even if the workspace is not visible. I also know that the Plot() method should not be called on any of those windows, so that code that executes there will not consume CPU resources (because the windows are not seen)... please correct me here if I am wrong about that.

My question is, do minimized windows in the currently open workspace work exactly the same way as open windows in a workspace that is not currently being seen? In other words, do they consume CPU resources to exactly the same extent as what I described above, or do minimized windows in the currently open workspace somehow consume more resources than windows in background workspaces? I hope this is clear...

(I am trying to figure out if it would be more CPU efficient to keep certain charts minimized in the current workspace, or open in another workspace open in the background, that's why I am asking.)

[NinjaTrader_Matthew]

Minimizing a chart would not prevent it from calculating in real-time. If you're looking to reduce the CPU cycles being consumed you would need to physically close out of the chart.

A minimized chart and a hidden workspace would have the same performance impact.

[Trader_55]

Minimizing a chart would not prevent it from calculating in real-time. If you're looking to reduce the CPU cycles being consumed you would need to physically close out of the chart.

A minimized chart and a hidden workspace would have the same performance impact.

Thanks, that's what I assumed, just wanted to confirm. Also, is there any way we can call a function in the code of an indicator that would indicate to us whether the chart was minimized or in a background workspace? That would allow the code in the OnBarUpdate() call to just return (effectively saving CPU resources) instead of going through the indicator calculation, when the chart was not being seen. If this is not possible, would it be possible to add as a feature request in the next release? Anything that helps NT to be more efficient for calculations would be a big benefit, and it should be possible to do by exposing a method like that in NinjaScript, if one does not already exist...

[NinjaTrader_Matthew]

Hello,

There is not a supported method for doing so, however there maybe some tricks with C#/.NET you could use to accomplish this.

With that said, I will take these comments to development to consider adding this functionality potentially in a future version.

Please let me know if you have additional questions.

[Trader_55]

Hello,

There is not a supported method for doing so, however there maybe some tricks with C#/.NET you could use to accomplish this.

With that said, I will take these comments to development to consider adding this functionality potentially in a future version.

Please let me know if you have additional questions.

No further questions, unless you happen to know of someone else on these forums who has figured out how to do this with C#/.NET and can direct me to where that might be . Other than that, please just submit it to the team, it would be very helpful, and would greatly aid in performance under certain situations... you might even want to consider implementing it as default behavior, if possible. Thanks!

[sledge]

So what happens when you un-minimize?

You wait for calculations to happen?

Are these your own indicators?

What could be taking so long that CPU cycles are 'wasted'?

I don't see this making sense.

No further questions, unless you happen to know of someone else on these forums who has figured out how to do this with C#/.NET and can direct me to where that might be . Other than that, please just submit it to the team, it would be very helpful, and would greatly aid in performance under certain situations... you might even want to consider implementing it as default behavior, if possible. Thanks!

[Trader_55]

So what happens when you un-minimize?

You wait for calculations to happen?

Are these your own indicators?

What could be taking so long that CPU cycles are 'wasted'?

I don't see this making sense.

Imagine you had a simple moving average calculating on every tick (for example). While the chart is minimized, the calculations wouldn't happen. If the user then showed the window again, if this was built into Ninja of course, the NT framework should detect that the window was just restored and perform the calculations once to show the new values, then start calculating on each tick again.

If you were to do this on your own by returning from the OnBarUpdate call right away if the window was minimized, then while minimized that call wouldn't execute. Upon restoring the window, the next tick would cause it to recalculate and display the new values. I don't know how it would show up on the newly shown window before the very first tick came in though, haven't thought about that... but it wouldn't be much of an issue in an active market, I don't think.

Either way, it saves CPU cycles by not going through all the OnBarUpdate code while the window is minimized.

[koganam]

Imagine you had a simple moving average calculating on every tick (for example). While the chart is minimized, the calculations wouldn't happen. If the user then showed the window again, if this was built into Ninja of course, the NT framework should detect that the window was just restored and perform the calculations once to show the new values, then start calculating on each tick again.

If you were to do this on your own by returning from the OnBarUpdate call right away if the window was minimized, then while minimized that call wouldn't execute. Upon restoring the window, the next tick would cause it to recalculate and display the new values. I don't know how it would show up on the newly shown window before the very first tick came in though, haven't thought about that... but it wouldn't be much of an issue in an active market, I don't think.

Either way, it saves CPU cycles by not going through all the OnBarUpdate code while the window is minimized.

if (ChartControl.ParentForm.WindowState == FormWindowState.Minimized) return;

Just remember that, as usual, you will not get any official NT support using ChartControl functions, so do not bother to ask.

[Trader_55]

if (ChartControl.ParentForm.WindowState == FormWindowState.Minimized) return;

Just remember that, as usual, you will not get any official NT support using ChartControl functions, so do not bother to ask.

Hey, thanks a lot! I will try that out...

[sledge]

Hey, thanks a lot! I will try that out...

You can't be seriously hurting for CPU cycles using SMA?!!!!

Imagine you have one of these indicators that take a while to compute.

You'll lock up your system each time opening the window.

Unless you at 50-75%+ cpu and your order entries are lagging, I really don't see the need to save a cpu cycle.

[Trader_55]

You can't be seriously hurting for CPU cycles using SMA?!!!!

Imagine you have one of these indicators that take a while to compute.

You'll lock up your system each time opening the window.

Unless you at 50-75%+ cpu and your order entries are lagging, I really don't see the need to save a cpu cycle.

Actually, I am running some things that are quite a bit more compute-intensive than a single SMA, that was just an example. This is particularly useful because I have more than one instrument loaded... I can minimize a whole set of charts related to a particular instrument using hotkeys, and save CPU cycles on charts that I am not watching. If I want to then quickly switch instruments, the current set of charts gets minimized and the other instrument's charts come up. This is much faster than actually switching instruments and waiting for NT to load all the data from the server. While they are in the background these extra charts won't consume CPU cycles, which is very helpful. There will be a burst of activity when switching from one instrument to another, but that's not really all that bad, and it beats leaving things running the background consuming cycles for no reason.