3 ms·

Yeah I find the first few rules here ... fit for a very different era. Back then, some devs would do something much more complicated to try to be faster, and o

Yeah I find the first few rules here ... fit for a very different era. Back then, some devs would do something much more complicated to try to be faster, and often the overall program was worse off. Nowadays, some devs do something much more complicated, make the program 100x or 1000x slower than the simple obvious way, and think they're doing solid engineering because they're definitely not "prematurely optimizing", they made it so slow and convoluted that you could never accuse them of that!

titzer 3y ago
In my experience, those 1000x slower situations are because people cobble together things without understanding their underlying performance characteristics, and there's usually a bunch of defensive copying and other redundant working going on that just keeps getting compounded. Also, dynamic languages that don't have good VMs can end up boxing even the basic numbers in the language, so everything is crazy slow because the very bottom is allocating boxes all the time and hunting for properties in polymorphic objects. In JS, some frameworks are so poorly designed that they abuse objects in ways that make it difficult for the VM to make it fast. So even reasonable-looking code is crazy slow because of hitting hidden slowpaths in the JS implementation. Another thorn is hiding RPCs, DB queries, and other remote operations behind abstraction boundaries. When people think that .getFooBar() is as cheap as a field access, they have a tendency to not cache+pass forward, but just recompute it, which ends up generating a large amount of redundant queries. That will rack up your 1000x's pretty quick.