PDC05: Day Five (Five Things Every Win32 Developer Should Know)

It is probably fair to say that every Win32 knows, or ought to know, the writings of Raymond Chen (blog). I am a huge fan of his blog, titled "The Old New Thing." The five "things" were broken into two categories:

• Performance
• What you learned in school is wrong.
• Playing friendly with others.
• UI Issues
• Large fonts.
• Parent & owner windows.
• Asynchronous & synchronous input

The performance talk was primarily focused on disabusing us all of the notions teachers inclucated during our college years: the algorithm is the key limiter of performance. We often go to great pains to select between a linked list at O(n) or a tree at O(log n). Chen argued that CPU speed, and therefore algorithm, is not the most significant factor, latency to storage is. The latency chart he used was:

• WAN (1e9 - 2e9)
• CD (1e9)
• LAN (1e7-1e8)
• Hard drive (1e7)
  
  
• Main memory (25-50)
• L2 cache (5-10)
• L1 cache (1-2)
• CPU (1)

You can see the huge leap in latency when your application moves from memory to the hard drive, to fetch pages ejected from your working set for instance. On a smaller level, it is also clear from the chart that pointers are expensive. A data structure made of pointers, like a tree or linked list, is unlikely to have the next object in the cache, since it probably is not stored nearby to the original object. You can see this when your process has a high page fault count during particularly taxing processing. Arrays and some kinds of trees are cache-friendly because they collect nearby items together (called locality).

The discussion of playing friendly with others largely focused around not polling, since it hurts all processes on the machine, proper threading and the somewhat more controversial topic of scaling your feature set based on the system's metrics. Windows Vista offers a new API called IWinSat which allows you to interrogate the performance behaviors of the machine you are running on. Chen suggested you could enable or disable various features of the application based on those results. I guess I could imagine ruling out a complex range analysis, like a natural breaks, if the machine falls below certain performance thresholds. This would be a difficult position to mantain, since it goes against the It Just Works view.

The only item in the UI discuss which really engaged me was the breaking changes in Vista regarding DPIs. First off, the idea of "Large Fonts' is being removed from Windows with the advent of Vista. Instead, Vista will now support arbitrary DPIs, but largely in the set 96, 120, 144, 192. As a result, all applications should be tested in these DPI configurations. Also, an application should call the method "SetProcessDPIAware()" if it can handle different DPIs, otherwise Windows Vista will just lie to the application telling it the DPI is always 96 and then stretch the bitmap to fit the real resolution. Applications which are already DPI-aware will have to be patched by the vendors or risk loosing their hard work when Vista comes out. Chen firmly believes that DPI is the new "multi-monitor" feature. Developers should look hard at this area...