3 ms·

The advice above is seductive, but wrong. Obviously one should look at performance requirements when developing the software architecture and check if various s

by blub 11y ago

The advice above is seductive, but wrong. Obviously one should look at performance requirements when developing the software architecture and check if various stacks fulfill them. Ignoring performance is a gamble and in the worst case one might find that improving performance means rewriting everything.

CuriouslyC 11y ago
The sorts of performance issues that will require a complete application rewrite aren't the result of the software stack used, but algorithms/data structures/etc. If you are working in polynomial or exponential time/space it doesn't matter what language/framework/etc you use, your scaling capability will be limited. In my experience, if you set things up properly the only part of the server side stack that is unavoidably difficult to transition is the underlying data management layer. If you have good examples (outside of latency constrained applications like multi-player gaming and finance) where a decoupled micro-service architecture would need to be completely rewritten (rather than just rewriting hot services/aggressively caching), I'd love to hear them.
- blub 11y ago
  I don't see how that would work. Picking the wrong algorithm will almost never result in a rewrite of the whole app, unless the entire app consists of just one algorithm or someone has consistently failed to pick efficient algorithms. What do you do if you wrote your app in Python and you need high-performance multi-threading? What do you do if you chose Java and your heap is way too big? Get ready for a lot of pain, that's what.
  - CuriouslyC 11y ago
    Games are an easy example where bad choices can ripple up through the entire application. Specifically, the method you use to store and index geometry impacts the codebase in a lot of places. Likewise, the way you design the main world update loop, or the way you communicate events to clients in multiplayer tend to have a similar effect. As for the problems you specified, usually only a portion of your application work flow will require multi-threading or big mem support, in most non-latency constrained applications those portions of the work flow can easily be split off into independent services, which can be rewritten to be performant. Obviously there are client-only applications (for example, a 3D modelling package) where it makes sense to go straight to the high-performance solution, but even in that case there are exceptions (for example, PyMol).

by blub 11y ago

CuriouslyC 11y ago

The sorts of performance issues that will require a complete application rewrite aren't the result of the software stack used, but algorithms/data structures/etc. If you are working in polynomial or exponential time/space it doesn't matter what language/framework/etc you use, your scaling capability will be limited. In my experience, if you set things up properly the only part of the server side stack that is unavoidably difficult to transition is the underlying data management layer. If you have good examples (outside of latency constrained applications like multi-player gaming and finance) where a decoupled micro-service architecture would need to be completely rewritten (rather than just rewriting hot services/aggressively caching), I'd love to hear them.

blub 11y ago
I don't see how that would work. Picking the wrong algorithm will almost never result in a rewrite of the whole app, unless the entire app consists of just one algorithm or someone has consistently failed to pick efficient algorithms. What do you do if you wrote your app in Python and you need high-performance multi-threading? What do you do if you chose Java and your heap is way too big? Get ready for a lot of pain, that's what.
- CuriouslyC 11y ago
  Games are an easy example where bad choices can ripple up through the entire application. Specifically, the method you use to store and index geometry impacts the codebase in a lot of places. Likewise, the way you design the main world update loop, or the way you communicate events to clients in multiplayer tend to have a similar effect. As for the problems you specified, usually only a portion of your application work flow will require multi-threading or big mem support, in most non-latency constrained applications those portions of the work flow can easily be split off into independent services, which can be rewritten to be performant. Obviously there are client-only applications (for example, a 3D modelling package) where it makes sense to go straight to the high-performance solution, but even in that case there are exceptions (for example, PyMol).