FYI: Using NinjaTrader in a Virtual Machine Takes Significant Performance Hit

[ntbone]

This original thread was due to a performance problem changing symbols in charts and it was believed to be due to running in a virtual machine. The real culprit though is the <Recent Instruments></Recent Instruments> section of UI.xml. The virtual machine I have setup for trading had 1000's of instruments in this list which it accrued over the last year. The developer machine only had a few 100.

Clearing out the <Recent Instruments></Recent Instruments> list in UI.XML significantly improved performance when changing instruments in charts.

[NinjaTrader_ChrisL]

Hi ntbone, thanks for posting. I suspect it's either the limited RAM or slow disk speed on the VM. I've never seen this issue on a real hardware machine.

Kind regards,
-ChrisL

[ntbone]

The virtual machine is not the issue. I misdiagnosed the problem. When I transferred my documents from the VM to my machine to use directly the slowness was there and further debugging showed me that clearing the <RecentInstruments></RecentInstruments> fixes the problem. When this list gets large, it slows down chart loading in NinjaTrader.

Every time a symbol is loaded into a chart it is added to the <RecentInstruments></RecentInstruments> section of UI.xml. This file is written to disk every time as well. Once this <RecentInstruments></RecentInstruments> section gets large (even over 500) symbols there is a noticeable hit in performance in loading symbols into charts. It doesn't matter if its a symbol already in the list or a new one. This list never gets smaller so over time it can easily have 1000's of symbols as different instruments are looked at, even only once.

Why does the UI.Xml store so many in the recent list?
Why is the recent list not capped at some max # of items?

I'll be emailing support soon as with more details, reproducing workspace files and steps to illustrate the problem.

Also this thread should be renamed or deleted and I will start a new thread with the proper subject.

[NinjaTrader_ChrisL]

Hi ntbone, it looks like we fixed this in the Continuous build. The next update should resolve the issue.

Kind regards,
-ChrisL

[ntbone]

That is great news as this is a real problem for me right now. Any specifics about how this is fixed? Has the performance of the code using the list been improved or has the list simply have a cap as to the # of items? The performance impact is definitely larger than O(n).

I setup a reproduction using no code and fresh build of NinjaTrader on a native machine. When a 1000 instruments end up in that list its noticeable slower. It becomes drastically different as you get up to 2000 and then 3000 instruments. At 3000 instruments it takes seconds for a chart to load vs almost instantaneous.

Over the past 6 months I had noticed NinjaTrader getting more and more sluggish. I thought it was due to # of charts and the extra indicators I was putting on the charts. I was going through trying to optimize the performance of the custom indicators. It was by chance that I happen to notice just how much of a difference it can make.

I have custom code that measured the time to load charts and with an empty list its under 1 second and with 3500 symbols it takes over 5 seconds at least.

My work around at the moment is to manually delete the <RecentInstruments> in the UI.xml however it is not a great work around.

[NinjaTrader_ChrisL]

Hi ntbone, I do not have any information on how the core code was changed. From what I tested, the list still grows without a bounds. I am assuming they changed how the list is processed when the platform is running. Try it out once the next update comes along and we will go from there if you encounter the same issue.

Kind regards,
-ChrisL