Skip to content
十月 15, 2009 / wychi

Why use ETW in product?

Before I go further, here are some diagrams can help you get a whole understanding about ETW.

animated

Compared to default trace/OutputDebugString(), ETW has those advantages.

  1. Efficient
  2. Well-organized
  3. Configurable
  4. Cross modules
  5. Leverage with system events.
  6. Fully integrated with OS

Those features make ETW the best choice of instrumentation.

1. Efficient.

According to MS document, ETW is high-speed-low-overhead.

High speed: 1200 to 2000 cycle per logging event.

Low overhead: Less than 5% of the total CPU cycles for 20,000 events/sec

In my test, at least 3 times faster than OutputDebugString() in the case of enable ETW session. You can check my previous post for detail number and get the sample code.

Needless to say that ETW can be disabled anytime. If you have put OutputDebugString() in critical path, now is the time to change it.

2. Well-organized.

The ETW events carry more information for filtering / grouping such as Events / Channels / Levels / Tasks / Opcodes / Keywords. (a Manifest-based event provider)

You can check Writing an Instrumentation Manifest for the meaning of each type.

Think about hundred of thousand debug messages showing over DebugView. You will thank MS for this.

3. Configurable

Once you complete the instrumentation, you are no longer need to modify your code/app configuration.

Depends on whether the ETW session exists and interested providers’ GUID are assigned, ETW providers will be enabled or disabled at run-time.

Which means

  • you don’t have to re-start you application and can start to investigate issues on-site .
  • Only interested event providers will produce events.

What a great feature.

4. Cross modules

Having messages created from app-level to component-level under a specific task is very useful while integration debugging.

Now, use ETW,  we are able to collect data as a whole.

5. Leverage with systemevents.

It is often that we want to understand where the computation resource spend. Knowing how system reacts to your operations is the key to performance.

Therefore, it is very important that your debug or profiling data can works with system’s.

Here is the example of using XPerf.  The yellow and green dots is my task.

1

6. Fully integrated with OS

you can subscribe your events via EventViewer

6

After thinking all over again, I do believe ETW is the right way to go.

Practically, on my experience on .Net, publishing ETW events is also very easy. On the contrast, Consuming or visualizing the data is not that easy.

But, we do have to worried about the consumer. There are already a lot of ETW tools. Ex: TraceViewr, XPerf, ETViewer, logman.

Reference:

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: