http://blogs.msdn.com/b/ryanmy/archive/2005/05/27/422772.aspx
- Uniformity. If you're debugging systemic problems involving multiple components, and all the involved components use ETW, you can have them all deliver their information to a single log file with uniform, steady timestamps, and write a single application that parses them all.
- Speed. ETW is extremely fast for providers to use, since all the I/O is handled by the kernel instead of by your module. It typically takes only 1500-2000 cycles, depending on settings, to deliver an event and return to your code. One can easily deliver thousands of events per second even on ancient machines. We've achieved 20,000 events per second while only using 5% CPU load on a P3 500MHz! (Yes, we have machines that old in our perf testing labs -- not everyone who uses Longhorn will be using a modern machine!)
- （在我的機器上， 每次log 時間大概是 15 ~20 微秒Intel Duel CPU E2220, 2.4GHZ）
- Consistency. With fprintf() or other homebrew systems, logging tends to be very slow and intrusive and is thus usually compiled in. With ETW, logging is extremely fast; furthermore, since logging is turned on by a controller and is usually off by default, you can actually leave the ETW events in final shipping code! If problems are found in the field, send the tester an app that starts a trace and turns on the provider, then read it later. Many, many components in Longhorn will ship as ETW providers.
- Reliability. ETW isn't a new thing -- it's actually been in the OS and actively used since Win2K, and has been constantly refined since then. Furthermore, ETW is available in both user-mode apps and kernel components. (The latter access it through a MJ_SYSTEM_CONTROL IRP.) This leads to...
- OS cooperation. The Windows kernel can provide many highly useful events via ETW for diagnosing performance problems. Find out when and where disk I/Os, registry accesses, hard faults, and other performance problems happen! More on this later...
