If your code doesn't do what you want it to do, you have no business optimizing it.
To give an example, if I use software that calculates an "optimal" route for me to deliver packages to 40 customers, I rather have a slightly optimal route that's ready by the time I start driving, then that I've to wait another few years just to find out I could save a few seconds from my trip.
You've just given a perfect example of why the OP was correct, not a counterargument. In the above example, "what you want the code to do" is to give you a "slightly optimal route" in a reasonable amount of time. Your trade-off is that there might be more optimal routes if you ran the code for longer.
If you're prioritising performance over correctness, then you're seeking an answer that is "good enough" given your time-frame. If your code is doing that, then your code is doing what you want it to. Note that "good enough" is important here. If your code was giving you obviously wrong answers, blindingly fast, you wouldn't be happy. The answers have to at least look correct enough. Ideally you'd have a test suite that flagged your edge cases and bugs, so that when you had time to deal with them you could, even while you made the common cases run well enough and fast enough to keep your business ticking over.
In different fields people would prefer correctness over performance. For example, I'd rather receive my credit card statement a day or two later than usual than have all the numbers added up wrongly. (In this case where Australia Post (the underlying protocol) is slower than the generation and printing of my statement, this is especially true).