3 ms·

There is a lot of inherent complexity there though. Inherently VS needs to support multiple debugging engines and multiple transports to communicate with the de

There is a lot of inherent complexity there though. Inherently VS needs to support multiple debugging engines and multiple transports to communicate with the debuggee as well (remote vs local debugging). That's OK, two layers of dynamic dispatch is still fast in this context. Do we update call stack and locals window at the same time, or do we update each one as early as possible but show inconsistent data? Do we fetch call stack for all stopped threads, or do we wait until the user chooses to focus on a different thread/display all threads using Parallel Stacks windows? If Watch result is a collection, do we load its members or wait for the user to expand the tree? If call frame has changed, the strings in Watch need to be re parsed to refer to new variables. Do we do this work every time, or do we optimise for stepping in a single function? Is it worth it if only a few of the debugging engines can support that optimisation? Each Watch needs to be interpreted in a way that catches all exceptions and creates an error message instead of crashing the debuggee. If the user puts a breakpoint at the end of a loop and holds down F5, watching the Locals to decide when to switch to stepping, is that a supported use case? These are the product decisions that lead to the performance, not micro details of how the code was laid out to achieve the goals. I mean, I don't have access to their source code, so I could still be proven wrong. What's an example of a fast debugger?

fwlr 4y ago
>What’s an example of a fast debugger? My apologies in advance if this feels like a gotcha, but… Casey ended up swapping to RemedyBG for debugging. He made a video about why. From about 0:50 onwards he talks about the speed and feature set of the watch window https://m.youtube.com/watch?v=r9eQth4Q5jg https://m.youtube.com/watch?v=r9eQth4Q5jg Also, I don’t mean to be rude by ignoring all the questions you posed; they’re good questions, I just don’t have answers for them (I would hope the developers whose full-time job it is to build debuggers would, though).
- peterfirefly 4y ago
  > Casey ended up swapping to RemedyBG for debugging. Thank you! I had no idea it existed. The watch window in VS is slower on my 2GHZ laptop than the one in Turbo Debugger was on a 10MHz 8086. That simply makes no sense. I know that the compilers do more optimization and that the debugging info therefore has to be more complex today. It still makes no sense!
  - fwlr 4y ago
    Don’t get me started. I know I’m sounding like an incurable fanboy for Casey because I mention him in every comment, but it’s only because I am an incurable fanboy for him, his polemics about software being thousands of times slower than it should be these days strike a deep chord with me. In one of his rants he goes to the effort of booting up a version of Visual Studio from 20 years ago, on a 20 year old machine, to demonstrate that it really truly was way faster back then than it is now: https://youtu.be/GC-0tCy4P1U https://youtu.be/GC-0tCy4P1U at 36 minutes in.
    - peterfirefly 4y ago
      > https://youtu.be/GC-0tCy4P1U https://youtu.be/GC-0tCy4P1U That was a beautiful rant :)

fwlr 4y ago

>What’s an example of a fast debugger? My apologies in advance if this feels like a gotcha, but… Casey ended up swapping to RemedyBG for debugging. He made a video about why. From about 0:50 onwards he talks about the speed and feature set of the watch window https://m.youtube.com/watch?v=r9eQth4Q5jg https://m.youtube.com/watch?v=r9eQth4Q5jg Also, I don’t mean to be rude by ignoring all the questions you posed; they’re good questions, I just don’t have answers for them (I would hope the developers whose full-time job it is to build debuggers would, though).

peterfirefly 4y ago
> Casey ended up swapping to RemedyBG for debugging. Thank you! I had no idea it existed. The watch window in VS is slower on my 2GHZ laptop than the one in Turbo Debugger was on a 10MHz 8086. That simply makes no sense. I know that the compilers do more optimization and that the debugging info therefore has to be more complex today. It still makes no sense!
- fwlr 4y ago
  Don’t get me started. I know I’m sounding like an incurable fanboy for Casey because I mention him in every comment, but it’s only because I am an incurable fanboy for him, his polemics about software being thousands of times slower than it should be these days strike a deep chord with me. In one of his rants he goes to the effort of booting up a version of Visual Studio from 20 years ago, on a 20 year old machine, to demonstrate that it really truly was way faster back then than it is now: https://youtu.be/GC-0tCy4P1U https://youtu.be/GC-0tCy4P1U at 36 minutes in.
  - peterfirefly 4y ago
    > https://youtu.be/GC-0tCy4P1U https://youtu.be/GC-0tCy4P1U That was a beautiful rant :)