4 ms·

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 benchmarkin

by 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
  I think your last sentence sums it up perfectly. It does seem that we have different views on software. Rebutting your points would just rehash my above comment. The only new point I'd like to add is one that requires imagination. Imagine if we had adopted performance oriented mindset 20 years ago, instead of today and we solved the developer productivity conundrum that we both care about so much. What a wonderful state software would be in, where IDE's can be installed in seconds, each action is instant and the engineer is completely intimate with every aspect of their baby. This depth of knowledge offers a certain creativity that results in amazing things. It lets engineers rise above what is good for the business and gives them the freedom to push software to it's utter limit. That's evolution. That's progress. That's engineering. PS: The reason I quoted John Carmack specifically in my first comment is because he is such an engineer.

by waivek 9y ago

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
I think your last sentence sums it up perfectly. It does seem that we have different views on software. Rebutting your points would just rehash my above comment. The only new point I'd like to add is one that requires imagination. Imagine if we had adopted performance oriented mindset 20 years ago, instead of today and we solved the developer productivity conundrum that we both care about so much. What a wonderful state software would be in, where IDE's can be installed in seconds, each action is instant and the engineer is completely intimate with every aspect of their baby. This depth of knowledge offers a certain creativity that results in amazing things. It lets engineers rise above what is good for the business and gives them the freedom to push software to it's utter limit. That's evolution. That's progress. That's engineering. PS: The reason I quoted John Carmack specifically in my first comment is because he is such an engineer.