3 ms·
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
by 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 agoGames 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).