5 ms·

The “not all parts have to be performant, so you can make those parts clean” objection never sits well with me. And it’s not just the fact that clean code is pr

by fwlr 4y ago

The “not all parts have to be performant, so you can make those parts clean” objection never sits well with me. And it’s not just the fact that clean code is presented as universal and this claim is only introduced after you complain that clean code has made your code less performant (Casey was remarkably polite in pointing this out and Bob was very gracious in concurring, both of which were a delight to read). The reason it doesn’t sit well is that, in practice, it seems like most products don’t know what needs to be fast and so developers end up making almost everything slow. Casey gives many examples but the one that sticks out most in my mind is the Visual Studio watch window (about 25 minutes into https://m.youtube.com/watch?v=GC-0tCy4P1U https://m.youtube.com/watch?v=GC-0tCy4P1U). The watch window lets you pin variables you’re interested in and it will show you their current values as you step through the program’s execution. Invaluable for debugging. Visual Studio’s watch window is incredibly slow, to the point that it actually has a debounce so it will stop updating when you’re stepping quickly and only update once you’ve stopped quick-stepping. This seriously impacts its usefulness! To me, the watch window seems like it’s obviously one of those modules that needs to be running in milliseconds or less - but the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead. So in my mind, “write clean except where performance matters” comes with an almost fatal caveat, something like “you won’t know where performance matters”.

lazyasciiart 4y ago
> the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead That is a giant presumption.
- fwlr 4y ago
  It is slow, and I presume that’s because competent developers wrote it clean. It’s quite possible that it’s not clean either and was just written by developers incapable of performance or cleanliness. That possibility doesn’t detract from my argument - there’s no point in discussing performance or clean code with them if they’re incapable of either.
  - lozenge 4y ago
    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!

by fwlr 4y ago

lazyasciiart 4y ago

> the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead That is a giant presumption.

fwlr 4y ago
It is slow, and I presume that’s because competent developers wrote it clean. It’s quite possible that it’s not clean either and was just written by developers incapable of performance or cleanliness. That possibility doesn’t detract from my argument - there’s no point in discussing performance or clean code with them if they’re incapable of either.
- lozenge 4y ago
  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!