4 ms·

Hardware might be cheap at some scales, but what if your service gets popular? What it latency for a single request can't be improved with more cores? What if

Hardware might be cheap at some scales, but what if your service gets popular? What it latency for a single request can't be improved with more cores? What if your product is used by consumers who may have old hardware? or phones, or watches, or laptops and they want their battery to last? What if you consistently practiced at making high performance code, maybe then it wouldn't seem "unreadable" to you any more? What if Linq-like higher order functions weren't slow? https://github.com/jackmott/LinqFaster https://github.com/jackmott/LinqFaster What if slow software was common today because of modern attitudes, and I wasn't seeing any increase in stability or features to show for it?

deanCommie 9y ago
> what if your service gets popular? Then re-design for map-reduce, and scale horizontally > What it latency for a single request can't be improved with more cores? Then look into pre-computing and caching > What if your product is used by consumers who may have old hardware? or phones, or watches, or laptops and they want their battery to last? I thought we were talking about server requests? If we are, then offload this work to the server > What if you consistently practiced at making high performance code, maybe then it wouldn't seem "unreadable" to you any more? But it's not all about you. Unless you're working on a pet project, or you have the credibility and reputation to be the final call on a significant open source project, you might get hit by a bus tomorrow. Or, if you do a really good job, your company will need you to be a force multiplier to teach a dozen others to try to imitate you. Even if you're a "10x" programmer. And by the way, when you optimize code THIS much, any refactoring or tweaks to new features cause your optimizations to get tossed out, and you have to start over from scratch. > What if Linq-like higher order functions weren't slow? https://github.com/jackmott/LinqFaster https://github.com/jackmott/LinqFaster https://github.com/jackmott/LinqFaster#limitations https://github.com/jackmott/LinqFaster#limitations > What if slow software was common today because of modern attitudes, and I wasn't seeing any increase in stability or features to show for it? Except you are, and you don't even realize it. Optimizations like this blog post matter a LOT on client software. Be it apps, or websites - anything run on the client will need this kind of attention sometimes. But this guy is writing server software. Micro-optimizing on the server side the way he is doing is silly.
- alexandrnikitin 9y ago
  > But this guy is writing server software. Micro-optimizing on the server side the way he is doing is silly. Khm... What if you have millions of requests per second with tight latency requirements measured in milliseconds; and a bunch of business logic to fit into that. Such optimizations aren't so silly. There are different scenarios on both client and server sides.
  - dahauns 9y ago
    Heh. You mean, like the example in the article? :)
- ro_sharp 9y ago
  I'd suggest that OLTP applications where non-trivial amounts of state are shared between transactions are a reasonable counterexample where single core performance optimisation really matters.
pc86 9y ago
I don't want to pick one single thing about your response, because I agree with a good portion of it, but if you're developing for watches you're probably going to care about performance from the start and not have the GP's (completely valid in certain scenarios) attitude.

deanCommie 9y ago

> what if your service gets popular? Then re-design for map-reduce, and scale horizontally > What it latency for a single request can't be improved with more cores? Then look into pre-computing and caching > What if your product is used by consumers who may have old hardware? or phones, or watches, or laptops and they want their battery to last? I thought we were talking about server requests? If we are, then offload this work to the server > What if you consistently practiced at making high performance code, maybe then it wouldn't seem "unreadable" to you any more? But it's not all about you. Unless you're working on a pet project, or you have the credibility and reputation to be the final call on a significant open source project, you might get hit by a bus tomorrow. Or, if you do a really good job, your company will need you to be a force multiplier to teach a dozen others to try to imitate you. Even if you're a "10x" programmer. And by the way, when you optimize code THIS much, any refactoring or tweaks to new features cause your optimizations to get tossed out, and you have to start over from scratch. > What if Linq-like higher order functions weren't slow? https://github.com/jackmott/LinqFaster https://github.com/jackmott/LinqFaster https://github.com/jackmott/LinqFaster#limitations https://github.com/jackmott/LinqFaster#limitations > What if slow software was common today because of modern attitudes, and I wasn't seeing any increase in stability or features to show for it? Except you are, and you don't even realize it. Optimizations like this blog post matter a LOT on client software. Be it apps, or websites - anything run on the client will need this kind of attention sometimes. But this guy is writing server software. Micro-optimizing on the server side the way he is doing is silly.

alexandrnikitin 9y ago
> But this guy is writing server software. Micro-optimizing on the server side the way he is doing is silly. Khm... What if you have millions of requests per second with tight latency requirements measured in milliseconds; and a bunch of business logic to fit into that. Such optimizations aren't so silly. There are different scenarios on both client and server sides.
- dahauns 9y ago
  Heh. You mean, like the example in the article? :)
ro_sharp 9y ago
I'd suggest that OLTP applications where non-trivial amounts of state are shared between transactions are a reasonable counterexample where single core performance optimisation really matters.

pc86 9y ago

I don't want to pick one single thing about your response, because I agree with a good portion of it, but if you're developing for watches you're probably going to care about performance from the start and not have the GP's (completely valid in certain scenarios) attitude.