5 ms·

If you program using design patterns that are 10x slower, your application end up 10x slower, even after you've optimised the hot spots away, and the profiler w

If you program using design patterns that are 10x slower, your application end up 10x slower, even after you've optimised the hot spots away, and the profiler will not give you any idea that it could be still 10x faster.

rileyphone 4y ago
Not the case if your program is spending most of its time waiting, which is typical these days.
- whstl 4y ago
  Not necessarily in the general case. If the program is a single user, locally ran program, then sure. If it's some sort of backend or distributed service, this is just wasted performance that can be used to serve more users. Virtually every distributed service built today is able to take advantage of this. With a non-pessimal design, not only you are able to pay less money on servers in the long term, you're also able to delay complex scaling strategies. Scaling also costs money. Not to mention that building something with this kind of overhead also means that a lot developer time was spent in the first place, which is still expensive in our industry.
  - Zvez 4y ago
    using 'unclean' code practice will increase development costs. And more importantly - maintainability of such code. >Virtually every distributed service built today is able to take advantage of this most of built today services can take much more advantage in using better system design practices.
    - deleted 4y ago
      [deleted]
badsectoracula 4y ago
If your profiler doesn't show any hotspots (which is incredibly rare in practice) and your program is still slow, it means you can simply pick any of whatever functions/methods show up near the top to optimize. If your program isn't slow then you don't need to bother making it any faster. Even Michael Abrash, who specializes in code optimization, once explicitly wrote in his graphics programming black book that "The objective (not always attained) in creating high-performance software is to make the software able to carry out its appointed tasks so rapidly that it responds instantaneously, as far as the user is concerned. In other words, high-performance code should ideally run so fast that any further improvement in the code would be pointless [..] Notice that the above definition most emphatically does not say anything about making the software as fast as possible".[0] [0] https://www.jagregory.com/abrash-black-book/#understanding-high-performance https://www.jagregory.com/abrash-black-book/#understanding-h...
- saagarjha 4y ago
  > If your profiler doesn't show any hotspots (which is incredibly rare in practice) and your program is still slow, it means you can simply pick any of whatever functions/methods show up near the top to optimize. No, though s/any/many/ would make this true.
- jbverschoor 4y ago
  Sure.. but the overall performance is in the cpu/vm, kernel, OS, UI, vm, electron, node, browser, javascript vm. etc etc There are no hotspots. Computing has become lukewarm by default, and just like the globe, it's slowly heating up.
- fvdessen 4y ago
  Think of using slow patterns as using a slow programming language. After you've optimised your python program and eliminated all hotspots, the python profiler isn't going to say 'hey, this could be still 10x faster if rewritten in go'. Note that if you write a graphics engine, you aren't going to use python or even go, but something more like c, c++, rust, even though your code would be cleaner in python. Clean code techniques elevate your level of abstraction and prevent some problems, but at the (significant) cost of performance. It's of course always a matter of trade-offs and this matters more or less depending on which problem you are trying to solve.
paxys 4y ago
All of the advice in that article isn't going to bring your server latency for an API call down from 1000ms to 30ms, but rather from 30ms to 25ms. So sure, if you absolutely must optimize that 30ms call after you have fixed everything else then go ahead, but very few are at that stage or will ever get to that stage. And if you try to optimize that last 5ms at the expense of the much larger issues then you are actually making things worse.
- dmitriid 4y ago
  > All of the advice in that article isn't going to bring your server latency for an API call down from 1000ms to 30ms, but rather from 30ms to 25ms. Of course it will. If your backend service is already suboptimal, and running at 10x worse performance, optimizing that will give you, well, a 10x performance boost. Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top. Boom. You're operating close to the speed of light.
  - Zvez 4y ago
    >Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top. but you are actually talking about optimizing system design, and not reducing virtual functions calls :). And that the point of this thread: you need to optimize parts that slow you the most. So no, in most cases optimizing virtual calls won't bring you from 1s to 30ms
seadan83 4y ago
It's rare that its the algorithm and not the design that is slowing you down. Though, sometimes it is the algorithm slowing you down, just usually it's the design. As an example, I recently worked on a large system that was optimized to do a big data transformation in an efficient way. It turns out that data is transformed back to the original format later downstream. So much for the optimization... All that is to say, often it is the case that "simple > fast" Clean code at the time had a lot going forward it, and it was an improvement over a lot of JavaEE code that was written in absolutely procedural ways with less care for the developer reading the classes, functions, or individual statements compared to punching out near assembly-like code and moving on.
Zvez 4y ago
no take your tupical web service application. Even if you use design patterns that are 10x slower, your program will still be as fast as your DB and overall system architecture. And the choices on your DB schema, indexes and caches will have 100x more effect on your 99pp response time than design pattern you use.
- whstl 4y ago
  That's only true if the DB is equally as problematic, and you programming language/framework itself aren't compounding on the overhead caused by the "10x slower" architecture. On slower languages with slower runtimes, something that is 10x slower than normal code will have much more overhead than in the examples demonstrated by Casey. It won't be about "30ms vs 25ms" as some people are saying. In the past I remember seeing differences between 400ms and 20ms between JBuilder and .to_json in a critical endpoint in a Rails app, to give one example. Sure, one is "cleaner", but in the end it's a 20x overhead that has no place this case. Also, the myth that "processors spend time waiting for IO" that is spread across this thread is BS. In reality, that's only true for single-user programs. If the app is part of a distributed system, the CPU time can be used to serve more users. This allows you to significantly delay more complex scalability efforts, which is also precious developer (or DevOps) time. Not to mention that applying "Clean Code" in the first place also takes precious time, which could be used for features or anything making money, even optimizing the DB. Instead, this time is used to mess up the code in ways that have zero proven efficacy, and some developers instead think are terrible.
- WesolyKubeczek 4y ago
  If you can remove thinly spread overhead from your web framework or any wasteful ritual dance you make for each request, it might not be much, but it does add up over the course of 24 hours * number of workers to quite a bit.
- trashtester 4y ago
  I would argue that persistance and caching strategies are also design patterns. Of course, if you're not the tech lead/architect it may be out of your hands. If you're working with databases, performance often boils down to minimizing the number of times you have to access the database (over a multi-service stack, not just a single web service).
gjulianm 4y ago
Well, for starters, Amdahl's law exists. If you use design patterns that are 10x slower on a code path that takes only 0.5% of the execution time your application ends up 0.55% slower. And the profiler never tells you how faster can a code path be. It just tells you where are you spending most of your time so you can put the effort where it matters.
- trashtester 4y ago
  This is precisely the kind of situation where it's imperative to consider performance before starting to build a new system. When you hit Amdahl's law, it's because you (or someone else) has made decisions about the high level design/patterns to use in a system. To remove such bottlenecks, you may have to scrap the entire project and start over. For the inner loops, it's perfectly fine to leave most of the optimization for later. But for overall design, it needs to be right from the start. Time and time again, I see devs stuck in some paradigm (often front-end devs or low volumen RESTful microservices) that makes it almost impossible to handle non-trival data volumes or traffic, causing new products to fail.
  - gjulianm 4y ago
    I mean, you always hit Amdahl's law, and the point is that most often the time limits are not that related to the architecture. Let's say you do these "10x slower patterns" in a backend application, in the part where the DB model gets translated to a response to give the client... Yeah, maybe that pattern is slower but most of the time of the response is spent on the network and the DB response. I do agree that overall design needs to fit performance requirements but for the most part that has nothing to do with "clean code" patterns.

rileyphone 4y ago

Not the case if your program is spending most of its time waiting, which is typical these days.

whstl 4y ago
Not necessarily in the general case. If the program is a single user, locally ran program, then sure. If it's some sort of backend or distributed service, this is just wasted performance that can be used to serve more users. Virtually every distributed service built today is able to take advantage of this. With a non-pessimal design, not only you are able to pay less money on servers in the long term, you're also able to delay complex scaling strategies. Scaling also costs money. Not to mention that building something with this kind of overhead also means that a lot developer time was spent in the first place, which is still expensive in our industry.
- Zvez 4y ago
  using 'unclean' code practice will increase development costs. And more importantly - maintainability of such code. >Virtually every distributed service built today is able to take advantage of this most of built today services can take much more advantage in using better system design practices.
  - deleted 4y ago
    [deleted]

badsectoracula 4y ago

If your profiler doesn't show any hotspots (which is incredibly rare in practice) and your program is still slow, it means you can simply pick any of whatever functions/methods show up near the top to optimize. If your program isn't slow then you don't need to bother making it any faster. Even Michael Abrash, who specializes in code optimization, once explicitly wrote in his graphics programming black book that "The objective (not always attained) in creating high-performance software is to make the software able to carry out its appointed tasks so rapidly that it responds instantaneously, as far as the user is concerned. In other words, high-performance code should ideally run so fast that any further improvement in the code would be pointless [..] Notice that the above definition most emphatically does not say anything about making the software as fast as possible".[0] [0] https://www.jagregory.com/abrash-black-book/#understanding-high-performance https://www.jagregory.com/abrash-black-book/#understanding-h...

saagarjha 4y ago
> If your profiler doesn't show any hotspots (which is incredibly rare in practice) and your program is still slow, it means you can simply pick any of whatever functions/methods show up near the top to optimize. No, though s/any/many/ would make this true.
jbverschoor 4y ago
Sure.. but the overall performance is in the cpu/vm, kernel, OS, UI, vm, electron, node, browser, javascript vm. etc etc There are no hotspots. Computing has become lukewarm by default, and just like the globe, it's slowly heating up.
fvdessen 4y ago
Think of using slow patterns as using a slow programming language. After you've optimised your python program and eliminated all hotspots, the python profiler isn't going to say 'hey, this could be still 10x faster if rewritten in go'. Note that if you write a graphics engine, you aren't going to use python or even go, but something more like c, c++, rust, even though your code would be cleaner in python. Clean code techniques elevate your level of abstraction and prevent some problems, but at the (significant) cost of performance. It's of course always a matter of trade-offs and this matters more or less depending on which problem you are trying to solve.

paxys 4y ago

All of the advice in that article isn't going to bring your server latency for an API call down from 1000ms to 30ms, but rather from 30ms to 25ms. So sure, if you absolutely must optimize that 30ms call after you have fixed everything else then go ahead, but very few are at that stage or will ever get to that stage. And if you try to optimize that last 5ms at the expense of the much larger issues then you are actually making things worse.

dmitriid 4y ago
> All of the advice in that article isn't going to bring your server latency for an API call down from 1000ms to 30ms, but rather from 30ms to 25ms. Of course it will. If your backend service is already suboptimal, and running at 10x worse performance, optimizing that will give you, well, a 10x performance boost. Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top. Boom. You're operating close to the speed of light.
- Zvez 4y ago
  >Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top. but you are actually talking about optimizing system design, and not reducing virtual functions calls :). And that the point of this thread: you need to optimize parts that slow you the most. So no, in most cases optimizing virtual calls won't bring you from 1s to 30ms

seadan83 4y ago

It's rare that its the algorithm and not the design that is slowing you down. Though, sometimes it is the algorithm slowing you down, just usually it's the design. As an example, I recently worked on a large system that was optimized to do a big data transformation in an efficient way. It turns out that data is transformed back to the original format later downstream. So much for the optimization... All that is to say, often it is the case that "simple > fast" Clean code at the time had a lot going forward it, and it was an improvement over a lot of JavaEE code that was written in absolutely procedural ways with less care for the developer reading the classes, functions, or individual statements compared to punching out near assembly-like code and moving on.

Zvez 4y ago

no take your tupical web service application. Even if you use design patterns that are 10x slower, your program will still be as fast as your DB and overall system architecture. And the choices on your DB schema, indexes and caches will have 100x more effect on your 99pp response time than design pattern you use.

whstl 4y ago
That's only true if the DB is equally as problematic, and you programming language/framework itself aren't compounding on the overhead caused by the "10x slower" architecture. On slower languages with slower runtimes, something that is 10x slower than normal code will have much more overhead than in the examples demonstrated by Casey. It won't be about "30ms vs 25ms" as some people are saying. In the past I remember seeing differences between 400ms and 20ms between JBuilder and .to_json in a critical endpoint in a Rails app, to give one example. Sure, one is "cleaner", but in the end it's a 20x overhead that has no place this case. Also, the myth that "processors spend time waiting for IO" that is spread across this thread is BS. In reality, that's only true for single-user programs. If the app is part of a distributed system, the CPU time can be used to serve more users. This allows you to significantly delay more complex scalability efforts, which is also precious developer (or DevOps) time. Not to mention that applying "Clean Code" in the first place also takes precious time, which could be used for features or anything making money, even optimizing the DB. Instead, this time is used to mess up the code in ways that have zero proven efficacy, and some developers instead think are terrible.
WesolyKubeczek 4y ago
If you can remove thinly spread overhead from your web framework or any wasteful ritual dance you make for each request, it might not be much, but it does add up over the course of 24 hours * number of workers to quite a bit.
trashtester 4y ago
I would argue that persistance and caching strategies are also design patterns. Of course, if you're not the tech lead/architect it may be out of your hands. If you're working with databases, performance often boils down to minimizing the number of times you have to access the database (over a multi-service stack, not just a single web service).

gjulianm 4y ago

Well, for starters, Amdahl's law exists. If you use design patterns that are 10x slower on a code path that takes only 0.5% of the execution time your application ends up 0.55% slower. And the profiler never tells you how faster can a code path be. It just tells you where are you spending most of your time so you can put the effort where it matters.

trashtester 4y ago
This is precisely the kind of situation where it's imperative to consider performance before starting to build a new system. When you hit Amdahl's law, it's because you (or someone else) has made decisions about the high level design/patterns to use in a system. To remove such bottlenecks, you may have to scrap the entire project and start over. For the inner loops, it's perfectly fine to leave most of the optimization for later. But for overall design, it needs to be right from the start. Time and time again, I see devs stuck in some paradigm (often front-end devs or low volumen RESTful microservices) that makes it almost impossible to handle non-trival data volumes or traffic, causing new products to fail.
- gjulianm 4y ago
  I mean, you always hit Amdahl's law, and the point is that most often the time limits are not that related to the architecture. Let's say you do these "10x slower patterns" in a backend application, in the part where the DB model gets translated to a response to give the client... Yeah, maybe that pattern is slower but most of the time of the response is spent on the network and the DB response. I do agree that overall design needs to fit performance requirements but for the most part that has nothing to do with "clean code" patterns.