Comment by timmisiak | Hacker News Reader

Comment by timmisiak | Hacker News Reader

Parent Full thread

The overhead varies depending on how cpu/IO bound the application is. IO isn't really affected, so IO bound applications tend to not see a big slowdown. In theory, you could see a very large slowdown in the worst case, but in the average case for a "medium sized" process the slowdown would be noticeable but not affect the usability. This technology isn't based on tracepoints, it's based on in-process cpu emulation. The emulation overhead is on the order of 10-20x in many cases, whereas tracepoint overhead would be on the order of 1000x I believe (maybe worse).

If there is something specific you dislike about the visuals of WinDbg Preview, let us know through the feedback hub or emailing windbgfb@microsoft.com. We realize that folks that have been using WinDbg for 20 years are likely to not be interested in a new UI, but we face 20 years of legacy code every time we want to add a new feature to the UI. As an example, the new WinDbg UI has a javascript window for writing scripts that extend and automate the debugger. It took us approximately 8x less time to implement in WinDbg Preview than what we estimated it would cost in the legacy UI (and a much more junior dev was able to do it as well). We want to innovate without disrupting folks that have effective workflows in WinDbg, so we really want to hear feedback on the new UI. If there are specific things that we can change to make you more efficient in the new UI, please let us know.

We realize that folks that have been using WinDbg for 20 years are likely to not be interested in a new UI, but we face 20 years of legacy code every time we want to add a new feature to the UI.

You can rewrite the UI code so it's easier for you to work on internally, but to the user it looks and acts like it was before --- but proceed cautiously[1]. I'm not against adding features and TTD sounds extremely useful, but having in the overview page some slight contradictions and a screenshot of a dumbed-down UI with obvious WTFs like the two duplicate lines really soured the first impression for me. (Looking at it again, I now see the path in the titlebar has been cut off, despite plenty of empty space after it...)

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

What duplicate lines are you talking about?

The debugger isn't written from scratch, just the UI. All of the underlying functionality is essentially the same, just in a more usable shell, and if you collapse the ribbon and retheme the UI to look like the 90s, you could almost squint and think it was the old WinDbg. The change is clearly very polarizing, but we're nearly at parity with what you could do in the old WinDbg UI, and we've already been able to give people features that we could have never dreamed of supporting in the old UI (not for lack of trying). The JavaScript support is just one example.

(Also, the cut-off title bar was an issue in the Fluent.Ribbon component we use, and I think it's fixed in an updated version that we're taking soon)

> What duplicate lines are you talking about?

I'd guess that userbinator is referring to the ribbon items "Command", "Memory", and "Source" where the group name on the ribbon has been given the same name as the single menu below it (in contrast to something like Word where the contextual ribbon items for a table are Table, with Design and Layout as children).

Oh OK, that makes sense then. Yeah, that's been fixed in current internal builds and will go out on the store soon.

Reply on news.ycombinator.com