Comparing code using WPF Perforate and Visual Profiler

For INPC code vs non standard code, there are some steps we can follow:
        private double? _q;
        public double? Qty
        {
          ... NotifyPropertyChanged(this,"Qty");
        }

        private double? _q;
        public double? Qty
        {
            get { return GetQty(0); }
            set { _bidQtys[0] = value; }  // by adding NotifyPropertyChanged(this,"Qty") here speed will pick  up to standard INPC

(1) generate stressfull/human data 1ms, 10ms 250ms and bind to WPF Xaml UI
            d = Observable.Interval(TimeSpan.FromMilliseconds(1)).Delay(TimeSpan.FromSeconds(20)).Subscribe((ms) =>
            {
                Random r = new Random();
                for (int i = 0; i < FakeData.Count; i++)
                {
                    FakeData[i].Qty = -1000 * r.NextDouble();

(2) Perforator:FRPS/DRAR higher=> data updates faster (Key Observation: INPC has 9x FRPS than non-standard that use intermediate storage
(3) VisualProfiler CPU %
 DispatcherInvoke -- Dispatcher Operation,  Increasing to high=> buggy code, e.g too many timer pushing UI

 Rendering Thread --- Unmanaged render pass (Brushed, tessalation, call DirectX), find only the visual element and draws 

the whole window at a 60 FPS as default, popularly called as Composition Thread , Graphics acceleration uses Channel 

Protocol to communicate with the other thread. High and increasing % => need to Profile to feed XPerf, GPUViwer, WPA, 

etc in Windows Performance ToolKit.

 Layout ---measure/arrange passes higher => variable/Compute control size, fast changing text, bad GPU/Box.

(4) 1ms -- most stressful  10ms -- Physical limit 16ms per frame =60 FRPS, 250 Human eyeball, Win8 App Fast= 100-200ms

Rx ObserveOn SubscribeOn

In WPF Window update UI code look like the follwoing:

    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            Observable.Interval(TimeSpan.FromSeconds(1)).ObserveOn(Dispatcher).Subscribe((i) => this.Title = i.ToString());
        }
    }
or

 Observable.Interval(TimeSpan.FromSeconds(1)).ObserveOn(this).Subscribe((i) => this.Title = i.ToString());

ObserveOn = Notify Observer on a Dispatcher
SubscribeOn = Subscribe/unsubscribe Observers on a scheduler, where background/task pool will run.

Useful Tools, scripts and Concept

Power Shell set path
====================
(Get-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' -Name PATH).Path

$oldPath=(Get-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' -Name PATH).Path

$newPath=$oldPath+’;C:\tools\snoop\’

Set-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' -Name PATH –Value $newPath

Power Shell:
============
get-childitem | select-string "double"  ( find string)
get-ChildItem -Path c:\log |select-string "error"

add user to admin  net localgroup Administrators /Add Domain\UserId

Color Hex converter
===================
http://www.colorschemer.com/online.html

Performance Tools and Concept
==============================

Vsync --- GPU sync up buffers and refresh rate so no Tearning (frame override previous one). If GPU does not finsh render before one VSync,
 then could CPU taking too long.
XPerf/WPA --ETW (CLR GC/ThreadPool/JIT events, Context Switching, CPU, Page Fault, Disk IO, reg access) best OS logging. some managed code

PerfView --- Managed code, Stacks (CPU,Disk IO, GC Head Alloc,Image Load, Managed Load), Stats(GC, JIT,Event)

Some details on PerfView:g 
=========================
(1) Memory -> Task Snapshot of Heap -> filter to your process -> Force GC-> dump your GC heap => can compare be
fore after closing of some part of UI to see if Memory get reclaimed.

(2)CPU Stack high CPU % path drill down can identify hot code.

(3) Run Command " your.exe" will still collect all ETW data so you have to drill down to "your.exe". But this will bracket the time you are interested in.  The other is "Collect"

(4) PerfView is for  managed code. So before any analysis, use VMMap to check workingset break down: Heap vs. Managed Heap size. Also, Task manager private Memory column can tell if Memory stay high and increasing even after some view are closed or running for a long time.

(5) Diff requires open two stack viewer of dump to diff. If Comparison to baseline show positive MB=> memory increase or baseline reclaimed GC Heap after GC dump and your app GC Dump.
(6) Click on a row in diff stack => trace back to root where you can start to analyze source code for who is holding heap memory.
(7) Wall Clock Analysis: Collect ->check Thread Time-> get 3 Thread time view stack in collected data.
(8) CPU_TIME, BLOCK_TIME= waiting for eg disk access come back, PAGE_FAULT= Virtual Ram. Ctx Menu Include Item/Back button can focus/exit on CPU_TIME.
(9) Zoom in = Select two cell -> set time range 
(10) Thread Time (With Task)--- charge Child task related time to Parent Task so time will be for the child  real work not in the task. Next use Include item can zoom in to the code in the thread that use Wall Clock time.