NexusFi: Find Your Edge


Home Menu

 





Ninja Soft Page Faults


Discussion in NinjaTrader

Updated
    1. trending_up 1,394 views
    2. thumb_up 1 thanks given
    3. group 1 followers
    1. forum 3 posts
    2. attach_file 0 attachments




 
Search this Thread

Ninja Soft Page Faults

  #1 (permalink)
sniffy
alask
 
Posts: 7 since Oct 2009
Thanks Given: 0
Thanks Received: 5

Does anyone have millions and millions of soft page faults when running Ninja ?

I have gazillions of them.

Reply With Quote

Can you help answer these questions
from other members on NexusFi?
MC PL editor upgrade
MultiCharts
ZombieSqueeze
Platforms and Indicators
NT7 Indicator Script Troubleshooting - Camarilla Pivots
NinjaTrader
Better Renko Gaps
The Elite Circle
Trade idea based off three indicators.
Traders Hideout
 
Best Threads (Most Thanked)
in the last 7 days on NexusFi
Diary of a simple price action trader
26 thanks
Just another trading journal: PA, Wyckoff & Trends
24 thanks
Tao te Trade: way of the WLD
22 thanks
My NQ Trading Journal
16 thanks
HumbleTraders next chapter
9 thanks
  #3 (permalink)
 
ratfink's Avatar
 ratfink 
Birmingham UK
Market Wizard
 
Experience: Intermediate
Platform: NinjaTrader
Broker: TST/Rithmic
Trading: YM/Gold
Posts: 3,633 since Dec 2012
Thanks Given: 17,423
Thanks Received: 8,425



sniffy View Post
Does anyone have millions and millions of soft page faults when running Ninja ?

I have gazillions of them.

Depends more on the working set size and the PF Delta (i.e. rate), if the baseline PF Delta is in the 2-5k range during normal use for a 500Mb footprint I'd say that's very normal. PF Delta on mine will jump to 12-15k when I switch workspaces but its still instant.

All OO type software programs tend to destroy low-level caches, hence the desire for heaps of DDR3. Not really a worry given the level of functionality we get in exchange, only a real worry if you get into hard page fault territory, then you have a system dog on your hands...

Travel Well
Visit my NexusFi Trade Journal Reply With Quote
Thanked by:
  #4 (permalink)
sniffy
alask
 
Posts: 7 since Oct 2009
Thanks Given: 0
Thanks Received: 5

So for all those thousands who are secretly dying to know ...

The background is that I have a spawned Form that creates price bars/other objects and is drawn and updated by a multi-layered graphics process that uses Bitmaps for buffers. This gives me double buffering with the drawing taking place in memory, then the painting of only those elements that have changed taking place in the Paint event handler.

However, I had left in place in my Form constructor, the setStyle instruction to use .Net double buffering. (I think the default for Forms is double buffering). So I changed that to not use double buffering ( I was already doing it manually through the Bitmap buffer after all).

Here is my complete setStyle list:

this.DoubleBuffered = false;
this.SetStyle(ControlStyles.SupportsTransparentBackColor, true);
this.SetStyle(ControlStyles.AllPaintingInWmPaint, true);
this.SetStyle(ControlStyles.OptimizedDoubleBuffer, false);
this.SetStyle(ControlStyles.UserPaint, true);
this.SetStyle(ControlStyles.ResizeRedraw, true);

Getting rid of the .Net double buffering reduced my soft page faults PFDelta from a background level of circa 450 with quite frequent peaks of 6/7 K and even up to 10-20K, by more than half. By double buffering x double buffering I presume that I was probably setting up a nice chain of unnecessary page faults.

Has there been any noticeable performance degradation ? None whatsover. The Bitmap double buffering and other anti-flicker options in the setStyles are clearly doing their job.

Not that there was any apparent visual issue before this change other than the unsettling number of soft page faults. However when you are waiting for confirmation of a fill or whatever, every little edge can obviously be very valuable.

In the process of trying to track down the reasons for these page faults I also noticed that I was allocating the Bitmaps in a way that didn't make sense, and sorting this out seems to have reduced the page fault regime further, and sorted a very small Dispose issue.

I also tried different options in the Bitmap allocation statement. I found that there was no apparent effect either on perceived graphics performance, or on the page fault annoyance. I currently use this:

Bitmap newBitmap5 = new Bitmap(rightPanel.Width, rightPanel.Height, PixelFormat.Format32bppPArgb);

So where am I now?

I have a baseline PFDelta of about 300 with peaks/spikes up to about 1K. Perceived graphics performance is still excellent with not a sign of flicker. Reducing the number of soft page faults was not the objective, gaining an understanding of why they seemed so high was.

Reply With Quote




Last Updated on February 23, 2013


© 2024 NexusFi™, s.a., All Rights Reserved.
Av Ricardo J. Alfaro, Century Tower, Panama City, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada)
All information is for educational use only and is not investment advice. There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
About Us - Contact Us - Site Rules, Acceptable Use, and Terms and Conditions - Privacy Policy - Downloads - Top
no new posts