> One main take-away for me was that you could improve performance by one order of magnitude over the baseline basically by just doing a good job and avoiding b

> One main take-away for me was that you could improve performance by one order of magnitude over the baseline basically by just doing a good job and avoiding basic mistakes. The resulting code is still well readable and maintainable. In most scenarios, this is where you should stop. I’ve done a lot of performance work but never heard this expressed so clearly before. Thanks - I’m stealing that. I’ve found exactly the same thing in my own work optimising text CRDTs. Just writing crdt code in a straightforward, correct way, without unnecessary allocations (and ideally using some good data structures) will get you very, very far. But there’s another order of magnitude available to anyone interested in using exotic, task specific data structures. I suspect the same is true in just about every field of computer science. Write good code in go / c# / Java / JavaScript / etc and 99% of the time, performance will be just fine. Well, so long as you don’t do anything silly like pull in immutablejs. But there’s usually 10-100x more performance available if you really try. If you want some examples, I highly recommend Algorithms for Modern Hardware, available for free online: https://en.algorithmica.org/hpc/ https://en.algorithmica.org/hpc/