5 ms·

> If I may, a rebuttal. Of course - when it's performing well, it's what this site shines at. > I see no reason that developer time cannot be optimized in a

> If I may, a rebuttal. Of course - when it's performing well, it's what this site shines at. > I see no reason that developer time cannot be optimized in a performance-first methodology Well clearly it can but it won't be nearly as much of a priority. Just like performance isn't as much of a priority when focusing on developer time. It's not clear what you're specifically rebutting in this section. We're both agreeing that developer-performance will improve significantly less in this model. And unresponsive text editor gives at most what a 3x slowdown in performance. Very little of a programmer's time is actually inputting text or data. While let's take the other extreme to show a point: Building a distributed transactional relational data driven application from scratch (because our tools weren't built because people would have been optimizing performance of late 90s hw) would be a 1,000x loss of developer productivity. The scaling factor of productivity just utterly dwarfs human interface performance. > There is no technological reason why Visual Studio 2017 should not run on a 5 year old laptop, yet that is the state we are in. True, but almost everyone would rather 2017 VS not run on a 5 year old laptop, then the best available product right now be Visual Studio 2005 era functionality highly optimized so it can still run on a 5 year old laptop.

waivek 9y ago
If text editors slowed down by 3x, I'd be happy. The latency I am complaining about is orders of magnitude higher than 3x. This is the most rigorous benchmarking that I am aware of: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ Each of those tables show that the difference in performance is not 3x but at least an order of magnitude, if not more. I think this is where our disagreement stems from. Your next point is valid, it would not make sense to develop such an application from scratch. However, I'm not talking about rebuilding from scratch merely prioritizing performance. This can be done by learning from Data Oriented Design where developers give a lot of importance to performance critical issues such as cache locality. This can be done without rewriting our tools from scratch, it just means that the developer will have to understand how memory works. It's not a tools issue, it's a knowledge issue. Your last point on Visual Studio makes me want to re-iterate the core of my argument: Performance and developer time optimizations need not be mutually exclusive.
- BoiledCabbage 9y ago
  > Performance and developer time optimizations need not be mutually exclusive Completely agreed. But since they're not mutually-exclusive why aren't you happy with the status quo? As stated we already can work on some perf improvements while focusing on developer productivity. I believe the reason why you aren't is logically, you'd rather the balance be shifted more towards performance. Which makes sense, but is illustrative of why saying "they aren't mutually exclusive" isn't a counterpoint. We're both discussing where the focus should be - not that the only options are all are nothing. If non mutually-exclusive were the solution, you wouldn't be happy to see this change and a shift towards performance. > Each of those tables show that the difference in performance is not 3x but at least an order of magnitude, if not more. I think this is where our disagreement stems from. Agreed. But taking sublime text as an example. I see peak ide/editor is roughly 7x faster across various tests, and slowest ide/editor is roughly 7x slower. Even combining both we see at most a 50x change in technical measures. Not in human productivity. The majority of the time people are sitting waiting. I think most people would argue that it doesn't take user 50x as long to write any program in Eclips/IDEA as it does in GVim. So that technical slowdown while annoying has a significantly lower impact on user performance. Any my argument isn't that users shouldn't have to know about performance, or that performance is bad, it's that resources spent on performance come from being spent on productivity. Here is an alternate view: Writing most software improves developer performance (text editors, communication tools, file system drivers, languages, compilers...). That better software ecosystem allowed developers to then write more / better software. Over some timescale we can approximate this as P(t2) = P(t1) * e^(rt). Where P(x) is developer productivity at time x. And t is a timespan. And r is the "rate of return" or productivity improvement by writing software. Saying a developer now needs to spend 30% of their time on performance means we now have: P(t2) = P(t1) e^(.7 * r * t). Due to exponential growth this means significantly less productivity over the long term. This is no different than annually getting 20% returns or 13% returns in the stock market. I sounds like a little, but over a long time scale (or a high scaling rate) this adds up significantly. Meaning right now in 2017 we'd be using a decade or older technology (If peak performance slowdown had hit in some year in the past). Overall I appreciate the debate and enjoy hearing different opinions. In this one, I feel we may just have different values here in the software space. I feel in an ideal world a developer would spend zero-time on performance. Since we don't live in an ideal world we have to spend some, but every bit of time spent on performance is time not spent on building a product. So we should want to minimize the amount of engineering time focused performance. My take is that you feel differently.

waivek 9y ago

If text editors slowed down by 3x, I'd be happy. The latency I am complaining about is orders of magnitude higher than 3x. This is the most rigorous benchmarking that I am aware of: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ Each of those tables show that the difference in performance is not 3x but at least an order of magnitude, if not more. I think this is where our disagreement stems from. Your next point is valid, it would not make sense to develop such an application from scratch. However, I'm not talking about rebuilding from scratch merely prioritizing performance. This can be done by learning from Data Oriented Design where developers give a lot of importance to performance critical issues such as cache locality. This can be done without rewriting our tools from scratch, it just means that the developer will have to understand how memory works. It's not a tools issue, it's a knowledge issue. Your last point on Visual Studio makes me want to re-iterate the core of my argument: Performance and developer time optimizations need not be mutually exclusive.

BoiledCabbage 9y ago
> Performance and developer time optimizations need not be mutually exclusive Completely agreed. But since they're not mutually-exclusive why aren't you happy with the status quo? As stated we already can work on some perf improvements while focusing on developer productivity. I believe the reason why you aren't is logically, you'd rather the balance be shifted more towards performance. Which makes sense, but is illustrative of why saying "they aren't mutually exclusive" isn't a counterpoint. We're both discussing where the focus should be - not that the only options are all are nothing. If non mutually-exclusive were the solution, you wouldn't be happy to see this change and a shift towards performance. > Each of those tables show that the difference in performance is not 3x but at least an order of magnitude, if not more. I think this is where our disagreement stems from. Agreed. But taking sublime text as an example. I see peak ide/editor is roughly 7x faster across various tests, and slowest ide/editor is roughly 7x slower. Even combining both we see at most a 50x change in technical measures. Not in human productivity. The majority of the time people are sitting waiting. I think most people would argue that it doesn't take user 50x as long to write any program in Eclips/IDEA as it does in GVim. So that technical slowdown while annoying has a significantly lower impact on user performance. Any my argument isn't that users shouldn't have to know about performance, or that performance is bad, it's that resources spent on performance come from being spent on productivity. Here is an alternate view: Writing most software improves developer performance (text editors, communication tools, file system drivers, languages, compilers...). That better software ecosystem allowed developers to then write more / better software. Over some timescale we can approximate this as P(t2) = P(t1) * e^(rt). Where P(x) is developer productivity at time x. And t is a timespan. And r is the "rate of return" or productivity improvement by writing software. Saying a developer now needs to spend 30% of their time on performance means we now have: P(t2) = P(t1) e^(.7 * r * t). Due to exponential growth this means significantly less productivity over the long term. This is no different than annually getting 20% returns or 13% returns in the stock market. I sounds like a little, but over a long time scale (or a high scaling rate) this adds up significantly. Meaning right now in 2017 we'd be using a decade or older technology (If peak performance slowdown had hit in some year in the past). Overall I appreciate the debate and enjoy hearing different opinions. In this one, I feel we may just have different values here in the software space. I feel in an ideal world a developer would spend zero-time on performance. Since we don't live in an ideal world we have to spend some, but every bit of time spent on performance is time not spent on building a product. So we should want to minimize the amount of engineering time focused performance. My take is that you feel differently.