Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Context switch logging with the Windows Event Tracing API (2014)

mollyrocket.com

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Context switch logging with the Windows Event Tracing API (2014)

#71

Post by j_s »

_yosefk wrote: post #6

This API is for people (both program authors and users) who really know quite well what they're doing, for very rare occasions, and the alternative/status quo was to not be able to get this info from the kernel at all. I imagine someone at MS thought they did a favor to people doing performance optimization by giving them something instead of nothing, perhaps they even had to fight to include this feature in the prod…

Yes, some people are able to use ETW effectively; there just isn't much motivation to share knowlege in this (commercial/Windows) space.

https://news.ycombinator.com/item?id=11418334

Re: Context switch logging with the Windows Event Tracing API (2014)

#72

Post by jjaredsimpson »

anentropic wrote: post #39
jjaredsimpson wrote: post #38

ETW isn't supposed to be written like this at all. MS has entire codegen toolchain that lets you define events in an xml manifest as part of your build process. This codegens a C header file which lets you fire events in your own code with a simple function call. When you want to correlate events from your own code and OS events you use a tool like XPerf which knows the OS events and can read your application manifes…

The API is still bad, it seems to have been badly designed regardless of whether the intended consumers are external developers or internal code

I don't see a well argued point that it is badly designed. It supports a powerful set of low overhead performance analysis tools.

If you want to correlate OS events, SQL server events, and application events, etc, you can get this working simply,correctly, fast and maintainable.

An api having a point of view about how it should be used doesn't make it a bad api.

Re: Context switch logging with the Windows Event Tracing API (2014)

#73

Post by jjaredsimpson »

kabdib wrote: post #43
jjaredsimpson wrote: post #38

ETW isn't supposed to be written like this at all. MS has entire codegen toolchain that lets you define events in an xml manifest as part of your build process. This codegens a C header file which lets you fire events in your own code with a simple function call. When you want to correlate events from your own code and OS events you use a tool like XPerf which knows the OS events and can read your application manifes…

> lets you define events in an xml manifest as part of your build process ... at which point you should run screaming.

Because all uses of xml are wrong by default? Something like:

Will codegen to a function like myevent_fire(int,timestamp,string).

Why is this bad? You separate the definition of event classes from their use sites and have correctness by default.

Re: Context switch logging with the Windows Event Tracing API (2014)

#74

Post by raarts »

burnstek wrote: post #51
ataylor284_ wrote: post #48

Earlier quoted context omitted.

This seems to be Microsoft's pattern. Make the APIs super low level and difficult to use, and build tooling on top to make it palatable. If you're doing simple stuff with Visual Studio, no problem, but as soon as you need to go deeper, good luck. I think it's probably embedded in MS developer culture, leftover from the old days when the ulterior motive was to make Windows "easy to develop for, difficult to port away…

"If you're doing simple stuff with , no problem, but as soon as you need to go deeper, good luck." This is how technology works in general. The deeper you go, the more abstractions you remove, the more difficult the job becomes.

Funny how for me this works completely the other way. Often people try to make things simple but in the process achieve exactly the opposite.

Re: Context switch logging with the Windows Event Tracing API (2014)

#75

Post by windowsworkstoo »

bjackman wrote: post #10
windowsworkstoo wrote: post #9

Yep, it's a difficult API, which has unfortunately meant the functionality, which works amazingly well, hasn't been learnt or adopted as much as it should have been. However reading this, it seems the author simply wanted to collect trace information. It's probably a documentation issue, but typically you would just use tools like xperf or logman to collect and analyze traces based on in built Windows providers. Ther…

> You can use tools like PerfMon to view logged information about your game, like how much working set it was using or how much disk I/O it did. But there is one specific thing that directly accessing Event Tracing gives you that you can’t get anywhere else: context switch timing.

PerfMon != logman/xperf, which exercise the same API this guy was struggling with.

Re: Context switch logging with the Windows Event Tracing API (2014)

#76

Post by slededit »

_yosefk wrote: post #6

This API is for people (both program authors and users) who really know quite well what they're doing, for very rare occasions, and the alternative/status quo was to not be able to get this info from the kernel at all. I imagine someone at MS thought they did a favor to people doing performance optimization by giving them something instead of nothing, perhaps they even had to fight to include this feature in the prod…

ETW is used in major pieces like the windows performance analyzer. There is zero possibility that this is a single person's pet project.

Re: Context switch logging with the Windows Event Tracing API (2014)

#77

Post by Varriount »

wildmusings wrote: post #57
jjaredsimpson wrote: post #38

ETW isn't supposed to be written like this at all. MS has entire codegen toolchain that lets you define events in an xml manifest as part of your build process. This codegens a C header file which lets you fire events in your own code with a simple function call. When you want to correlate events from your own code and OS events you use a tool like XPerf which knows the OS events and can read your application manifes…

It has gotten much better since then. These days the preferred logging API is the Tracelogging API https://msdn.microsoft.com/en-us/library/windows/hardware/dn... . No schemas, no XML, no build integration required, no decoding problems. As for collecting logs, WPR is currently the best tool. There's a great .NET library for both logging and reading recorded events. http://www.nuget.org/packages/Microsoft.Diagnostics…

How is that API supposed to be used from C (not C++)?

Re: Context switch logging with the Windows Event Tracing API (2014)

#78

Post by wildmusings »

Varriount wrote: post #77
wildmusings wrote: post #57

Earlier quoted context omitted.

It has gotten much better since then. These days the preferred logging API is the Tracelogging API https://msdn.microsoft.com/en-us/library/windows/hardware/dn... . No schemas, no XML, no build integration required, no decoding problems. As for collecting logs, WPR is currently the best tool. There's a great .NET library for both logging and reading recorded events. http://www.nuget.org/packages/Microsoft.Diagnostics…

How is that API supposed to be used from C (not C++)?

This page has sample code in both C and C++, look at the #ifdef's: https://msdn.microsoft.com/en-us/library/windows/hardware/dn...
Post reply on HN