3 ms·

> The big one however is going from 200 Python servers to 4 Erlang ones If your rewrite or refactor gives you a 10X in performance, that's not an optimization,

> The big one however is going from 200 Python servers to 4 Erlang ones If your rewrite or refactor gives you a 10X in performance, that's not an optimization, but a bugfix. Unless you are a researcher who have just found a revolutionary algorithm.

coldtea 3y ago
Or you just used a crappy inefficient architecture or algorithsm etc. Just because they were slow doesn't make them bugs, nor does using something faster in a rewrite means it's a bugfix.
- btreecat 3y ago
  They could be design bugs as in it was broken/buggy by design.
  - Difwif 3y ago
    Or it was quick and cheap to build, by design. It's perfectly acceptable to optimize for time to market first if you can eat the other costs.
  - Adkron 3y ago
    Could those design-bugs be in the language's runtime?
znpy 3y ago
I’m going to be cynical and say that if they went from 200 to 4 servers they were probably spawning the python code via cgi, synchronously…
anonymoushn 3y ago
Why? Most software is at least 10x slower than necessary for reasons that don't require inventing new algorithms.
- astrobe_ 3y ago
  It is a matter of mindset. I work on software with soft real time, storage capacity and power consumption constrains, there is a constant flux of "small" feature requests and I cannot even "throw hardware at the problem" at will like as they apparently did, until it became unquestionable that the problem had to be fixed properly. I'd recommend to adopt this mindset even if one doesn't have those constrains - without erring on the side of "faster than necessary" though - because it's usually difficult to assess how much time and money are leaking because of the inefficiencies one accepts in the name of questionable reasons. They were sort of lucky to have a bill to show it to them. A proactive stance in this regard goes a long way.

3 ms·

> The big one however is going from 200 Python servers to 4 Erlang ones If your rewrite or refactor gives you a 10X in performance, that's not an optimization,

by astrobe_ 3y ago

coldtea 3y ago
Or you just used a crappy inefficient architecture or algorithsm etc. Just because they were slow doesn't make them bugs, nor does using something faster in a rewrite means it's a bugfix.
- btreecat 3y ago
  They could be design bugs as in it was broken/buggy by design.
  - Difwif 3y ago
    Or it was quick and cheap to build, by design. It's perfectly acceptable to optimize for time to market first if you can eat the other costs.
  - Adkron 3y ago
    Could those design-bugs be in the language's runtime?
znpy 3y ago
I’m going to be cynical and say that if they went from 200 to 4 servers they were probably spawning the python code via cgi, synchronously…
anonymoushn 3y ago
Why? Most software is at least 10x slower than necessary for reasons that don't require inventing new algorithms.
- astrobe_ 3y ago
  It is a matter of mindset. I work on software with soft real time, storage capacity and power consumption constrains, there is a constant flux of "small" feature requests and I cannot even "throw hardware at the problem" at will like as they apparently did, until it became unquestionable that the problem had to be fixed properly. I'd recommend to adopt this mindset even if one doesn't have those constrains - without erring on the side of "faster than necessary" though - because it's usually difficult to assess how much time and money are leaking because of the inefficiencies one accepts in the name of questionable reasons. They were sort of lucky to have a bill to show it to them. A proactive stance in this regard goes a long way.