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

51–60 of 78 posts

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

#51

Post by burnstek »

ataylor284_ wrote: post #48
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…

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.

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

#54

Post by pmontra »

pmontra wrote: post #11
wheaties wrote: post #4

Earlier quoted context omitted.

This site worked great on my android phone. Much better than most responsive sites I've visited. Add to that it loaded quickly. I'd say it's a good design.

There are overlaps between paragraphs due to Opera's autoreflow after pinch to zoom.

Downvote me as much as you want, reality doesn't change. If you use Opera with force reflow and you zoom in, text of different paragraphs overlap and you can't read anything.

Bad design as expected when trying to format HTML as if it was PDF. The designer has to adapt to unpredictable user agent settings, not the other way around.

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

#55

Post by ygra »

ibiza wrote: post #14

Somewhat related, Jeff & Casey take down another MS API: How to draw a rectangle with Direct2D. http://braid-game.com/news/2009/01/the-jeff-and-casey-show-o...

Most of that sample is actually how to deal with the Window API to get a window that redraws itself when resized. All that has nothing to do with Direct2D. Drawing the rectangle is just three lines, actually.

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

#56

Post by mikestew »

If by "worst API ever" he means "didn't do it the way I'd do it", he might be right. But if what he really means is "biggest pain in the arse to use", I give the crown to the AirWatch API. Not only do few of the functions work they way that they are documented, the sample code will never work (nor is it even close to a representation of how one might use it in the real world"), and my fave: you have to misspell the parameter name going in, but when it comes out it will be spelled right. So my code is littered with "no, that's not a typo; it's what the API requires" and "don't forget to spell the parameter correctly when referencing the return value". What amounted to maybe 100 lines of code against that API took me days of experimentation and cursing the useless docs. On our internal wiki, I documented what I was writing with a preface: "in 30 years of writing against APIs of all shapes and sizes, including ISAM data engines on IBM 370 mainframes from the 70s and open source projects written by some dude during an all nighter of coding and bong hits, the AirWatch API is by far the most steaming pile of poo I've ever had the displeasure of working with."

To me it's obvious that no one within the AirWatch organization ever used the API. They couldn't without running into the egregious bugs I have. My suspicion is that someone said "we should have an API", wrote a spec and shipped it offshore, then never checked the work that came back.

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

#57

Post by wildmusings »

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.Tracing....

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

#58

Post by holmak »

markbnj wrote: post #46
bluetomcat wrote: post #37

Earlier quoted context omitted.

Win32 API is the most horrendous collection of badly named, nonsensical types and functions I've ever encountered in my career. Back in the mid 90s I was learning how to program and understanding a Win32 "Hello world" was a royal pain compared to everything else I was doing. Functions with more than 8 parameters were the norm, structs with tens of members had to be manually initialised before calling them. And don't…

Easy to call it idiotic today, after twenty years of evolution, but it's a little silly to do so. The windows API was written in C, and as such they needed some way to accommodate multiple dispatch in the message loop using statically typed parameters. That same entry point handled literally hundreds of different message types for every operation in the system. From my perspective it was pretty well designed for its…

SDL is written in C, and it has a much more pleasant way of dealing with heterogeneous event types. There is a struct called SDL_Event, which you fill by calling SDL_PollEvent() until there are no more events to read. The struct is a (discriminated) union of all the possible event types. (It even wraps the Win32 API, so it is very directly comparable -- it is returning the same events!)

https://wiki.libsdl.org/SDL_PollEvent

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

#59

Post by ataylor284_ »

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.

The point is that there was no effort to use meaningful abstractions and a coherent interface at the API level. The art of building a good product is finding the right level of abstraction for your audience, and I don't think 3rd party developers are well served here, although internal Windows performance engineers might be.

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

#60

Post by atomwaffel »

zeveb wrote: post #25
modarts wrote: post #23

Earlier quoted context omitted.

People still disable JS in 2016? I take it that 80%+ of the web is horribly broken for you guys.

> People still disable JS in 2016? I take it that 80%+ of the web is horribly broken for you guys. Yeah, it is — but it's better to have to enable JavaScript on a one-by-one basis when desired that to travel across the Internet executing random code and impairing one's privacy. Some websites require JavaScript to display images nowadays. What's wrong with ? Others require JavaScript to use the correct font. What's wr…

> Some websites require JavaScript to display images nowadays. What's wrong with ?

Lazy loading. By default, browsers will load all images as soon as the page loads. If you have a long article with potentially megabytes of images, this behaviour will seriously slow down the initial load, and many readers who jump early will still download a bunch of images that they never see. That's why many sites only load images as they are about to appear, but to do that, you can't use regular tags.

You're right in that JavaScript shouldn't be a requirement though. A good implementation will provide a regular inside a tag.

> Others require JavaScript to use the correct font. What's wrong with CSS?

Avoiding "flashes of invisible text"[1] when using web fonts. Unfortunately, different browsers have very different strategies for loading web fonts. Some of them will wait for the web font to load at any cost rather than showing a fallback font in the meantime. This means that you can be stuck for ages with everything in place except for the text, which is seriously irritating.

I've never implemented FOIT mitigation myself, but I assume that you could (and should) again provide a fallback in a tag. Even without it, the text will at least still display without JavaScript, just in the second font in the font stack.

[1] https://css-tricks.com/fout-foit-foft/

Post reply on HN