:
I made those relationship checks 10x as fast by just introducing a little caching, turning the checks from O(logn) to amortized O(1)--multithreading is an O(1) speedup, so improvements in algorithms will win just about 100% of the time, and this is a great example of that
Expressing strong support for Putnam here: When looking to make things faster, first try to improve/replace the algorithms, then retry to improve the algorithms, then again try to improve the algorithms. After that you may start to look for optimizations (and while doing that, keep an eye open for algorithm improvements).
It's also the case that an algorithm that was good once upon a time may become less suited to its ever expanding set of tasks as years go by, so a need to replace an algorithm isn't automatically a sign of a bad design.
Another way to think about this:
Saying that the game is slow because it is single threaded is similar to saying that I'm not rich because I'm only working 1 job. Working 2 jobs doesn't guarantee that I will double my salary. It's often easier to negotiate 1 high salary rather than 2. Worse, even if I did double my salary, it wouldn't be enough to make me rich. Finally, the nail in the coffin is that by working 2 jobs, I put each at risk because coordinating 2 full time jobs during the day is actually very difficult. The way to get rich is by concentrating on getting rich, not by concentrating on how many jobs you are working.
While I'm here, I want to put in a brief pug for SDL3. I think Putnam was earlier expressing some support for SDL3 sooner rather than later and I think that's the right idea (apologies if I'm putting words in your mouth Putnam). It doesn't have to give you a lot of value. The reason for doing it as early as possible is that there will be less changes made earlier in the development stream. The earlier to upgrade, the easier it is to do. When working on a long term project, understanding long term efficiencies is *very* important. Those little cleanup chores can easily suck up most of your time if you let them.
It's a bit like doing your dishes. If you clean as you cook, each thing takes only about 5 seconds to clean. If you leave it until after you eat your meal, it will take 1-2 minutes. If you leave it until the end of the week, all your meals take 2-3 times as long to cook because you are constantly fighting for counter/sink space. And then you have an extra 2 hours of really horrible cleaning of the kitchen. I once saw an interview with the wife of a Michelin star chef. She said her husband's food was OK, but for every day meals, she liked hers better. However, she said that he did everything in a third of the time because he kept the kitchen immaculate. This is also true of programming.
