Programmers know what this is: a plague of software engineering where developers scratch their butts ahead of time devising architectures and algorithms which should scale well under the envisioned future high load. Which, 99% of the times never happens but the code is an unmaintainable complex nightmare from the start. And when the high-load use-case happens it's almost always completely different from what originally thought so now you have two problems: solving the real problem of performing well under real circumstances and maintaining compatibility with the broken, defective horror that keeps the company cash flow coming. Anyway, this is just a rant on the observation that there's also the reverse use-case. After some 10 years of using my own backtesting software and suffering through the pain of waiting quite some time for simulations to complete, I eventually bit the bullet and addressed the known bottleneck. Took me some 2 hours to make the code run some 20x faster. Question is, did it matter that is was slow? Answer is no. 99% of the effort (and time) involved in backtesting a trading strategy goes in "coding" it. Thinking of the theoretical use cases, figuring out how to express that in code, realizing what the edge is and how to test if that can be replicated along various assets. And running the actual simulation to get feedback and improve. But the runtime is irrelevant. It really doesn't matter if it completes in 1 second or 1 day in the end because the data gathered after it takes anyways weeks to months and an Eureka moment to process and improve.
This is not a great title. premature birth premature ejaculation premature death premature optimization
Agree with paragraph #1 and #2. Paragraph #3 contradicts #2. You suffered pain for 10 years and then decided to finally fix it. Clearly it did matter that it was too slow.