3 ms·

There's a huge swathe of languages between Python and C++. On threads about Node's performance (which is somewhere in between) people regularly say that it's un

There's a huge swathe of languages between Python and C++. On threads about Node's performance (which is somewhere in between) people regularly say that it's unfair of developers to solely focus on devex, which is the argument here. > On multiple occassions I had to port parts of Python projects to C++ for performance reasons, and the amount of code you have to write (and time you need to spend) is mind blowing. Sometimes a single line of Python would expand to several files of C++, and you always had to redesign it somehow so that memory and lifetime management becomes feasible. Part of that is because it's designed for python. Using this benchmark example, the python code (without imports) is 36 lines and the go code is 70. Except, we're doing a 1:1 copy of python to go here, not writing it like you would write go. Most of the difference is braces, and the test scaffold. I'd also argue the go code is more readable than the python code, doubly so when it scales.

rbanffy 2y ago
> it's unfair of developers to solely focus on devex, which is the argument here. For most companies and applications, developer time is many orders of magnitude more expensive than machine time. I agree that, if are running applications that run across thousands of servers, then it's worth writing it in the most performant way possible. If your app runs on half a dozen average instances in a dozen-node K8s cluster, it's often cheaper to add more metal than to rewrite a large app.
- PhilipRoman 2y ago
  There is more to it than just time. If your app is customer facing (or even worse, runs on your customer's own resources), high latency and general slowness is a great way to make your users hate it. That can cost a lot more than few days of developer time for optimization.
  - rbanffy 2y ago
    There is, of course, a limit. OTOH, if your devex is so terrible you can’t push out improvements at the same cadence of your competitors, you are doomed as well.
- maccard 2y ago
  No, it’s more expensive to you, and you get to ignore the externalities. It’s like climate change - you don’t care because it doesn’t affect you. How many hundreds of hours are wasted every day by Jira’s lazy loaded UI? I spend seconds waiting for UI transitions to happen on that app. How much of my life do I spend waiting for applications to load and show a single string that should take 50ms to fetch but instead takes 30 seconds to load a full application?
  - lpapez 2y ago
    I don't know, but personally I've spent orders of magnitude more time debugging memory leaks in languages without GC than the time I've wasted waiting for shitty apps to load. Software bloat is a real thing, I agree, but it's a fact of life and in my opinion not a hill worth dying on. People just don't care. If you want proof of this, try to find a widely used Jira alternative which doesn't suck and doesn't need a terabyte cluster to run. There isn't one because most people just don't care about it, they care about the bottom line.
    - rbanffy 2y ago
      Not only that - when your ticket system becomes a Jira because of all the feature creep required, it’ll perform like a Jira. Perhaps a little better if you can implement more in less crazy ways (it seems to keep a lot of logic into a relational database, which is a big no-no for the long term evolution of your system).
    - sgarland 2y ago
      > People just don’t care. Devs don’t care, because they aren’t being forced to care, and they have loaded M3 MBPs, so they don’t notice a difference. I firmly believe that we’ll see more of a swing back to self-hosting in some form or another, be it colo or just more reliance on VPS, and when we do, suddenly performance will matter. Turns out when you can’t just magically get 20 more cores on a whim, you might care.
  - rbanffy 2y ago
    How many years of our lives would be saved if Jira was rewritten in Verilog and ran on the fastest FPGAs? Not much. I bet it spends most of the time looking up data on their massive databases, which do the best they can to cope with the data structures Jira uses internally. You could, conceivably, write a competitor from scratch in highly optimised Rust (or C++) and, by the time you have covered all the millions of corner cases that caused Atlassian to turn a ticketing system into Jira, you’ll have a similar mess.
- carlmr 2y ago
  >For most companies and applications, developer time is many orders of magnitude more expensive than machine time. For me the context was mostly working in DevOps CI/CD. Slow CI scripts slow down developer feedback and cost machine time as well as developer time. If your customers are your developers, performance engineering is about saving the expensive developer time. And if you ask me the effects are non-linear, too. If your build system takes 1 minute or 10 minutes for a diff build the time lost won't be a mere factor of 10. Any sufficiently long time and your developers will lose focus and their mental model, will start making a coffee, and maybe they might come back later to that work after 3 meetings that got scheduled in between.
igouy 2y ago
> Using this benchmark example, the python code (without imports) is 36 lines and the go code is 70. Look at the gz values and notice that longer programs might be faster programs: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ~ "How source code size is measured" https://benchmarksgame-team.pages.debian.net/benchmarksgame/how-programs-are-measured.html#source-code https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

rbanffy 2y ago

> it's unfair of developers to solely focus on devex, which is the argument here. For most companies and applications, developer time is many orders of magnitude more expensive than machine time. I agree that, if are running applications that run across thousands of servers, then it's worth writing it in the most performant way possible. If your app runs on half a dozen average instances in a dozen-node K8s cluster, it's often cheaper to add more metal than to rewrite a large app.

PhilipRoman 2y ago
There is more to it than just time. If your app is customer facing (or even worse, runs on your customer's own resources), high latency and general slowness is a great way to make your users hate it. That can cost a lot more than few days of developer time for optimization.
- rbanffy 2y ago
  There is, of course, a limit. OTOH, if your devex is so terrible you can’t push out improvements at the same cadence of your competitors, you are doomed as well.
maccard 2y ago
No, it’s more expensive to you, and you get to ignore the externalities. It’s like climate change - you don’t care because it doesn’t affect you. How many hundreds of hours are wasted every day by Jira’s lazy loaded UI? I spend seconds waiting for UI transitions to happen on that app. How much of my life do I spend waiting for applications to load and show a single string that should take 50ms to fetch but instead takes 30 seconds to load a full application?
- lpapez 2y ago
  I don't know, but personally I've spent orders of magnitude more time debugging memory leaks in languages without GC than the time I've wasted waiting for shitty apps to load. Software bloat is a real thing, I agree, but it's a fact of life and in my opinion not a hill worth dying on. People just don't care. If you want proof of this, try to find a widely used Jira alternative which doesn't suck and doesn't need a terabyte cluster to run. There isn't one because most people just don't care about it, they care about the bottom line.
  - rbanffy 2y ago
    Not only that - when your ticket system becomes a Jira because of all the feature creep required, it’ll perform like a Jira. Perhaps a little better if you can implement more in less crazy ways (it seems to keep a lot of logic into a relational database, which is a big no-no for the long term evolution of your system).
  - sgarland 2y ago
    > People just don’t care. Devs don’t care, because they aren’t being forced to care, and they have loaded M3 MBPs, so they don’t notice a difference. I firmly believe that we’ll see more of a swing back to self-hosting in some form or another, be it colo or just more reliance on VPS, and when we do, suddenly performance will matter. Turns out when you can’t just magically get 20 more cores on a whim, you might care.
- rbanffy 2y ago
  How many years of our lives would be saved if Jira was rewritten in Verilog and ran on the fastest FPGAs? Not much. I bet it spends most of the time looking up data on their massive databases, which do the best they can to cope with the data structures Jira uses internally. You could, conceivably, write a competitor from scratch in highly optimised Rust (or C++) and, by the time you have covered all the millions of corner cases that caused Atlassian to turn a ticketing system into Jira, you’ll have a similar mess.
carlmr 2y ago
>For most companies and applications, developer time is many orders of magnitude more expensive than machine time. For me the context was mostly working in DevOps CI/CD. Slow CI scripts slow down developer feedback and cost machine time as well as developer time. If your customers are your developers, performance engineering is about saving the expensive developer time. And if you ask me the effects are non-linear, too. If your build system takes 1 minute or 10 minutes for a diff build the time lost won't be a mere factor of 10. Any sufficiently long time and your developers will lose focus and their mental model, will start making a coffee, and maybe they might come back later to that work after 3 meetings that got scheduled in between.

igouy 2y ago

> Using this benchmark example, the python code (without imports) is 36 lines and the go code is 70. Look at the gz values and notice that longer programs might be faster programs: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ~ "How source code size is measured" https://benchmarksgame-team.pages.debian.net/benchmarksgame/how-programs-are-measured.html#source-code https://benchmarksgame-team.pages.debian.net/benchmarksgame/...