Performance on the WPF AllScripts Healthcare demo ...
Over the last month, several people have asked me why CPU is so high on the healthcare demo ...
I usually
- Ask if they are getting hardware acceleration? point them to Perforator or WPFPerf to check, and/or explain them the driver checks in case they have old drivers .... I also
- Explain to them that it is a demo; opting for slightly higher CPU if it can shave milliseconds of screen time is often not a bad decision for a demo. Overall, it was not originally architected as a sample ....and retrofitting that to be a good perf sample can likely compromise readability for those trying to use it to learn...
Last week, Christoph emailed me asking about the perf the same day that I was installing the demo to show it , so I "peeked" ...
In summary:
I cut the CPU consumption on my laptop ( 2.1 GHz ) significantly due to a possible tiny bug.. Taskmgr tells me CPU went down between 20 and 40% .. specially for the first screen...
In my laptop, the first screen is running at around 3% CPU, and the second screen is running at around 25 % ... [Both of these used to be much higher]
Here are the findings
There was this in the code
Chart.cs, Line 35 ... private const double timerFrameRate = 20.0; // 1000 / 200 = 5 fps .... Well last I checked, 1000 frames/20ms == 50 FPS ...
I am not sure if this is a bug or some one purposedly changed it later to 20 from 200.. ... but considering that the chart is updated once a second, 50 fps is way too much ...The line above is a big deal, cause you are running at least 5 charts ALL the time -- regardless of whether the charts are showing on the screen or not.. it is a demo after all.. and also because they actually change the screen (see #2 below)..
It is doing some funny stuff...
- Redraws each chart in "full"every second, Controlled by UpdateInterval Dep Property, which defaults to 1000 ms
- but then they refresh every 50 fps ( see #1) and it actually moves the canvas by 5 pixels every frame.. so technically data changes once a second but demo is still creating a dirty region and redrawing 50 fps...
Check in my code for # ONESECONDREFRESH ... This is how the app would behave if you were just refreshing the data once a second and letting it be.. this is how this app would likely behave in real life..
The demo uses Shapes & Paths to draw... Not sure why .. I tested it with StreamGeometries and works fine too .. Look at my code for #preprocessor NOTOPTIMIZED ... and check the differences.. sadly, that failed to yield a significant change on my side, but it might if doing software rendering.. I am guessing given this is once per second, it is not a huge deal ..
The demo itself does a little more drawing to make things pretty than a lot of people would do in a real scenario (e.g. they have code to draw shadows, real code might not do this)
The first and second screen pretty much stay in memory and running... this is one of the reasons the second screen is 25% CPU ... It does not stop updating the stuff on the first screen... This one I think is because it is a demo/prototype...
I also had time to fix this FAQ ... People have asked me about why the 3D flips some times don't work ...
The demo checks if I am running in PowerSaver mode .. and when I do, it does not do the cool 3D flips. ... Check AppWindow.xaml.cs, OnPatientRosterSelectionChanged ...
OK, those are a few of my findings while on a 2 hour flight to San Jose... I am zipping the code and putting it here.
When I have time I will check with Karsten to see if that is worth re-publishing .. I think if we are going to re-publish we should add a couple of extra changes like:
- using the 3DTools library from CodePlex to do the 3D rotation of the listbox... The latter change looks like more than a few hours worth of work because it is at the core of the layout for the whole app ... that is why I did not do it ...
Hope that helps some ... If I ever have time, I will look deeper into the second screen... I think that is still has a lot of room ... if any one peeks and finds stuff let us know..